Wierd interaction between calls to the bus and subsiqent Pending Calls

[John (J5) Palmieri]

This seems to be a problem in the Bus and not Python

Background:

I was trying to track down a bug in the python introspection code.  It
seemed that for hal-device-manager when introspection is turned on it
took a long time for the app to start up (close to the 25 second timeout
it seemed).  At first I thought it was Python GIL lock and reentrancy
problems.  That all turned out to be a red herring.

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.

What next?

I'm going to try to duplicate this in C and see if I can boil it down to
a test case but if anyone has any ideas or can hint in a direction to go
that would be great.
 
-- 
John (J5) Palmieri <johnp at redhat.com>