Race condition when using dbus_connection_send() from multiple threads sharing the same connection
Tom.Hughes at palm.com
Thu Sep 17 11:16:19 PDT 2009
I probably didn't explain my setup thoroughly enough. I'm using
libgdbus to hook dbus into a glib mainloop (and thus calling select()
through that). The issue is that dbus isn't toggling the DBusWatch
functions, so the mainloop does not get notified that it needs to do a
select() on that file descriptor ; the message then sits in the queue
until the next dbus_connection_send() call (which will notice there is
a message in the queue and attempt to send it out).
Note that the issue will never occur in a single-threaded application
because the io path mutex will always sucessfully be acquired and dbus
will set the watch to notify the mainloop.
On Sep 17, 2009, at 11:00 AM, Avery Pennarun wrote:
> [Disclaimer: I haven't actually looked at how the dbus send queue
> code works]
>> As a result, the message is in the outgoing queue,
>> but is essentially stuck and won't be sent until the next call to
> 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
> seen, some other part of the program is doing select() on the socket
> and will write the output queue to the socket when select() returns
> If you don't select() on your socket on a regular basis, you shouldn't
> expect dbus to work properly. This has something to do with the
> DBusWatch functions, I think. If you're using the dbus-glib bindings,
> this probably happens automatically for you.
> 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.
More information about the dbus