Wierd interaction between calls to the bus and subsiqent Pending Calls

[John (J5) Palmieri]

On Fri, 2005-12-16 at 16:35 -0500, Havoc Pennington wrote:
> On Fri, 2005-12-16 at 16:15 -0500, John (J5) Palmieri wrote:
> > > 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.  
> 
> I'm not sure I understand this fully from the descriptions you guys are
> giving, but I don't think the app is broken. The pending call should not
> get its notification callback until the blocking call is done (because
> no reentrancy back into the same thread is allowed while in a blocking
> call). So it's a bug if the pending call is notified while blocking.
> However, it's also a bug if the pending call isn't immediately notified
> after the blocking completes.
> 
> Blocking in dbus _does_ block the thread that's blocking entirely.
> Otherwise you can't possibly write correct code.
> 
> Havoc

What I was saying that if you do a blocking call after you do a pending
call it is sort of a broken way of writing an app but it is known
behavior as you pointed out.  That is besides the point though.

What the python bindings are doing is creating a pending call to get
introspect data so we don't block and that all happens "in the
background".  However if a user makes a blocking call and the introspect
data has not returned yet (or you have not gone back into the mainloop
to process it) we call block_pending_call on the introspect pending call
and hold off on calling the method the user called.  Upon completion of
the introspect block we go through all the motions and block on the
user's call.

What is at issue is that if we make a call into the bus like AddMatch
for some reason when the code hits the pending_call_block on the
introspect it sits there for 25 seconds (the default timeout) in poll
(according to strace) and then returns successfully.  If you don't call
into the bus everything works fine.  Also running it in gdb causes it to
work fine.  

hmm interesting running with DBUS_VERBOSE on I think I just caught the
problem but have no idea what is causing it.  It shows that we enter
block_pending_call but then immediately after it shows a call to
send_with_reply_and_block.  This is what most likely blocks us for 25
seconds.  I can't fathom why it is doing that.

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