Race condition when using dbus_connection_send() from multiple threads sharing the same connection
patrick at phys.hawaii.edu
Thu Sep 17 12:28:34 PDT 2009
Note: I have a more descriptive bug regarding this issue posted at
> > As a result, the message is in the outgoing queue,
> > but is essentially stuck and won't be sent until the next call to
> > dbus_connection_send().
> Since dbus_connection_send() is supposed to be asynchronous, and
> socket buffers aren't infinite, there must *always* be a possibility
> that the data won't go out right away. In most applications I've
Right - and there are two reasons why data won't go out right away.
1) The socket buffers are full
2) The I/O path wasn't acquirable
Reason 1 is handled by the DBusWatch mechanism. Reason 2 is completely
unhandled right now. If it happens, the message won't be sent until
the next outgoing message is sent, which could happen much, much, much
> Anyway, I don't think the right place to fix this is at
> dbus_connection_send() time; it sounds like your application doesn't
> have its mainloop setup correctly.
The only way this is an application problem is if the requirement is made
that dispatches cannot be handled until the application returns from
dbus_watch_handle(). Unless I'm missing something, I don't see that anywhere
in the documentation.
Note that I'm not convinced this is purely a threading problem, as I mentioned
in an earlier message (though I dunno, I haven't written a testcase yet).
If DBusWakeupMainFunction calls dbus_connection_dispatch() (which is probably
stupid, yes, but I dunno, there might be a reason) then this exact same problem
More information about the dbus