dbus_pending_call_set_notify race

Havoc Pennington hp at redhat.com
Thu Nov 30 09:00:40 PST 2006

Alexander Larsson wrote:
>> A workaround might be to set_notify and then immediately check if the 
>> pending call is completed; if it isn't then you should get the notify.
> Isn't that racy too? The notify might be called twice. It should really
> be don inside dbus_pending_call_set_notify race so it can lock properly.

IIRC the reply is supposed to be atomically "used up" whenever something 
takes it from the pending call. i.e. I think this works:

  if (!completed(pending))
    /* we know that the notify will be called in the main loop thread,
     * since no reply has arrived
       /* the reply may or may not have arrived at this point, so
        * see if we can get it
       reply = get_reply(pending);
       if (reply == NULL)
          /* we know the main loop thread already handled the reply after
           * we checked for completion
          /* we know we got the reply before the main thread and notify
           * will never be invoked

it'd be worth double-checking though that it works that way...

Of course this is pretty inconvenient. Maybe instead of the idle 
handler, we could offer a function that essentially did the above - "set 
notify or return reply" - but even with that convenience function it's 
annoying, since your notifier will be run in the main loop thread and 
your set_notify_or_get_reply is in a different thread, and it's probably 
a pain to code things in two ways so you can handle the reply in either 


More information about the dbus mailing list