dbus_pending_call_set_notify race

[Havoc Pennington]

Alexander Larsson wrote:
> I just found something i think is racy in the dbus API.
> 
> I'm calling dbus_connection_send_with_reply(), possibly not on the same
> thread as the mainloop. This queues the message for delivery. It also
> returns a DBusPendingCall so i can track recieving the message.
> 
> However, what if the mainloop gets scheduled and gets a reply before I
> call dbus_pending_call_set_notify. Won't this mean I will miss the
> callback? Maybe it should detect that case and call the function (from
> an idle (==timeout of zero))?
> 

Right, you would miss the callback (though the reply would be stored in 
the PendingCall). The idle is the only fix I can think of... I guess I 
would do that inside set_notify (if the reply is already there when you 
set_notify, then queue an idle that will notify if the reply is still 
unused and do nothing if the reply was already taken)

This is a little unusual case (using threads *and* async callbacks) so 
hopefully it isn't really biting a lot of people yet.

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.

Havoc