Wierd interaction between calls to the bus and subsiqent Pending Calls

[John (J5) Palmieri]

On Fri, 2005-12-16 at 19:51 +0100, Kevin Krammer wrote:
> 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.

Nope this is not the issue.  If you call a blocking call after you do a
pending call then your app is broken.  This is calling a pending call
after a blocking call to the bus is made.  

DBus.AddMatch - blocking
Hal.Manager.GetDevices - pending 

remove the AddMatch and GetDevices returns immediately.

Of course I have yet to be able to duplicate it in C so it still might
be something to do with the locks in python.

-- 
John (J5) Palmieri <johnp at redhat.com>