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

[Patrick Allison]

Note: I have a more descriptive bug regarding this issue posted at

https://bugs.freedesktop.org/show_bug.cgi?id=23584

> > 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
later.

> 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
would occur. 

Patrick