Race condition when using dbus_connection_send() from multiple threads sharing the same connection

[Tom Hughes]

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.

Tom

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
>> 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
> 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
> true.
>
> 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.
>
> Avery