Wierd interaction between calls to the bus and subsiqent
John (J5) Palmieri
johnp at redhat.com
Fri Dec 16 13:15:51 PST 2005
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>
More information about the dbus