Race condition in send_with_reply_and_block()

[Simon McVittie]

On 22/07/13 17:15, Victor Stinner wrote:
> My application is calling
> dbus_bus_add_match() and dbus_bus_remove_match() in a thread, and our
> D-Bus loop is running in another thread, (and the mainthread is doing
> sometimes else ;-)).

The executive summary is "threads + libdbus = anyone's guess". Use
GDBus, part of GLib, if you can. It's much, much better-designed for
multi-threaded applications (at the cost of somewhat higher overhead,
because it is always multi-threaded internally).

Note that libdbus < current git master is not thread-safe unless you
call dbus_threads_init_default() before using any other libdbus API, and
libdbus < 1.6.0 weren't thread-safe on Unix at all due to a faulty
implementation of recursive mutexes.

As far as I can tell, dbus-glib has never been thread-safe, and should
not be used in multi-threaded applications (but then, dbus-glib should
not be used in any new code anyway).

> dbus_connection_send_with_reply_and_block() should not "hijack" the
> role of the main loop (handle watch / dispatch). As suggested in the
> following comment, dbus_connection_send_with_reply_and_block() should
> rely on the D-Bus loop

For better or worse (mostly worse, tbh), the libdbus API is that you can
call dbus_connection_send_with_reply_and_block() without having any sort
of main loop running: it can't rely on "the right thing" happening in
another thread.

At this point I'm rather reluctant to put a lot of time (mine or anyone
else's) into fixing threaded use-cases that don't currently work, at the
risk of breaking threaded use-cases that *do* (semi-accidentally)
currently work.

I'm not convinced that it's possible to give libdbus well-designed
multi-threading without a redesign and API break, at which point you
might as well use GDBus instead.

    S