Wierd interaction between calls to the bus and subsiqent
kevin.krammer at gmx.at
Fri Dec 16 10:51:27 PST 2005
On Friday 16 December 2005 19:44, John (J5) Palmieri wrote:
> What I found:
> D-Bus was blocking in a poll on the first call to Hal. Commenting out
> the add_match calls to the bus that happen before the first call to Hal
> made the Hal call succeed in a timely manner (note that it always
> succeeds but it is a question on how long it takes). Looking even
> further it seemed that if I made any calls to the Bus at all it would
> cause pending calls to take a long time to call their handlers. This
> doesn't happen for blocking calls. We hit this in the Python bindings
> because our internal Introspect uses pending calls.
If you mean that a blocking call after a pending call makes the pending delays
the pending result for a very long time, then I have seen this as well.
If the pending result is received while the blocking call is waiting for its
result, the pending result is correctly received but not dispatched.
A call to dispatch after the blocking call (or a blocking call sequence) is
finished, immediately processes the earlier received pending results.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20051216/3e4aebed/attachment.pgp
More information about the dbus