Wierd interaction between calls to the bus and subsiqent Pending Calls

[Kevin Krammer]

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.

Cheers,
Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20051216/3e4aebed/attachment.pgp