Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

[Randell J. <rj...@wg...>]

>In the past week I worked on the echo example and tried to figure out
>why it did not work.
>
>It occurred to me that the multi threading cannot work since libdbus
>does a poll and dbus-cplusplus does a poll as well on the same file
>descriptor which cannot be safe.
>
>My echo-client blocked for 25 secs after a client issued a Hello
>request. The server's response let the dispatcher return from the poll
>call. The following watch_ready read the message from the socket but had
>it not ready to dispatch before the client issued its blocking poll.
>Then the response was ready but the client could not be woken up.
>
>My first idea was that we must somehow be able to wake up the client,
>then I realized that this code was located in libdbus. The second idea
>was to have a separate connection for each server and client object.
>
>To ensure that the dispatcher is not polling the client connections and
>accidentally receive responses an additional dummy dispatcher must be
>created and set as default_dispatcher while creating the client
>connections.
>
>Please have a look at my patch.
>It fixed the echo example for me.

The patch didn't seem to be attached - where can it be found?  Can you
send it directly for me to try?

I've noticed problems before with 25-second delays when starting up a
dbus-c++ server in response to a dbus method.

Following is what I wrote on Sep 17th.  From what you're saying, the
problem may not be caused by a timing hole, and there's no retry -
what's probably happening is a following watch-ready is kicking things
off.

I worked around the problem (painfully) by waiting for a signal from the
service before sending it a method.

  Randell

From: Randell Jesup <rj...@wg...>
Subject: Problem with waiting for a service to be available
To: db...@li...
Date: Thu, 17 Sep 2009 17:09:31 -0400

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:

(From what dbus-monitor sees, what my Qt apps sees, and what another
application would probably see):

:1.17 sends AddMatch to DBus for NameOwnerChanged signal

Assumes: we've connected NameOwnerChanged signal to internal Qt slot
Time goes by, and then we start up the server for ServiceName

signal NameOwnerChanged for :1.35
:1.35 sends Hello to DBus
signal NameOwnerChanged for ServiceName
:1.35 sends RequestName to DBus for ServiceName

At this point, the listener notices NameOwnerChanged, and sends a method
(init()) to to ServiceName.  Note that it may do this as soon as
NameOwnerChanged for ServiceName is delivered to :1.17

:1.17 sends init to Servicename
:1.35 sends AddMatch to DBus for ServiceName

Wait around 15-30 seconds....

:1.35 finally acts like it got method init() (and I think sends a reply,
         which dbus isn't configured to let dbus-monitor see)
:1.17 sends version to ServiceName

Note that if ServiceName is already registered before :1.17 starts up,
there are no unusual delays.

Simplified profile (sorry, I didn't have the initial signal of
NameOwnerChanged for :1.35 in here)

mc	1253210449	162033	1	:1.35	/org/freedesktop/DBus	org.freedesktop.DBus	Hello
sig	1253210449	204469	10	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged
mc	1253210449	204727	2	:1.35	/org/freedesktop/DBus	org.freedesktop.DBus	RequestName
mc	1253210449	223718	52	:1.17	/com/foo/ServiceName	com.foo.ServiceName	init
mc	1253210449	250102	3	:1.35	/org/freedesktop/DBus	org.freedesktop.DBus	AddMatch
mc	1253210474	268186	53	:1.17	/com/foo/ServiceName	com.foo.ServiceName	version
mc	1253210475	397637	54	:1.17	/com/foo/ServiceName	com.foo.ServiceName	command

So, I assume the delay is a retry within dbus to deliver the message
before giving up.  Even if it's queued in dbus, why isn't it delivered
when :1.35 (ServiceName) does the AddMatch?

Also note: the previous owner of ServiceName had been killed, and
appropriate NameOwnerChanged had occurred.  From another run:

sig	1253221607	797520	17	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged
mc	1253221607	797769	11	:1.44	/org/freedesktop/DBus	org.freedesktop.DBus	ReleaseName
sig	1253221607	867286	18	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged

The first NameOwnerChanged is for com.foo.ServiceName, the second is for :1.44


-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
rj...@wg...