dbus_pending_call_set_notify race

[Alexander Larsson]

On Thu, 2006-11-30 at 10:09 -0500, Havoc Pennington wrote:
> 
> 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.

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.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a short-sighted neurotic senator on the run. She's a provocative 
cigar-chomping pearl diver prone to fits of savage, blood-crazed rage. They 
fight crime!