>There seems to be a designed-in timing hole in the DBus architecture, or
>perhaps it isn't obvious (or explained) how you're supposed to wait for
>a service to be available. Note that "ServiceName" is using dbus-c++
>(the working "git" tree branch with ecore integration). Perhaps even
>it's a dbus-c++ issue, though it doesn't seem like it.
>
>
>If (like Qt's wrapper does to update ::isValid()) your application
>watches for NameOwnerChanged to know when a destination is available to
>send methods to, the ordering of operations leaves a timing hole. To
>whit:
Just to reiterate and verify I'm not (or dbus-c++ isn't) doing something
wrong:
When I receive signal "NameOwnerChanged" for ServiceName, if I send a
method to ServiceName *immediately* will it arrive there reliably (and
quickly)? I'm seeing a 15-30 second delay (seems like a retry within
the dbus daemon) from when I send the method and the recipient appears
to receive it. I know it's not queuing within Qt since dbus-monitor
shows the init method being sent immediately.
DBus version I'm running is "D-Bus Message Bus Daemon 1.0.3"
This is the dbus-c++ code for aquiring the name (assumes a patch to
dbus-c++ I sent in a few days ago to get the return code from
dbus_bus_request_name()):
DBus::Connection conn = DBus::Connection::SessionBus();
// Make sure we never get two instances running!
try
{
int result;
syslog(LOG_INFO,"requesting name");
if ((result = conn.request_name(SERVER_NAME,DBUS_NAME_FLAG_DO_NOT_QUEUE)) !=
DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
{
syslog(LOG_ERR,"Request_name returned %d",result);
ecore_shutdown();
return 1;
}
}
catch(DBus::Error &e)
{
syslog(LOG_ERR,"Error: Request name failure: %s",e.message());
ecore_shutdown();
return 1;
}
--
Randell Jesup, Worldgate (developers of the Ojo videophone)
rjesup at wgate.com