dbus_pending_call_set_notify race

[Havoc Pennington]

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:

  send_with_reply(&pending)
  set_notify(pending)
  if (!completed(pending))
    /* we know that the notify will be called in the main loop thread,
     * since no reply has arrived
     */
     ;
  else
    {
       /* 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
           */
       else
          /* 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 
thread.

Havoc