Fwd: Re: Race condition in send_with_reply_and_block()

[rony]

On 22.07.2013 20:51, Simon McVittie wrote:
> 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.
A few years ago, studying the DBus specifications I have come to believe that libdbus is the
official reference implementation, not GDBus:

Having written a bridge/function package for a scripting language that is compilable (and got tested
on) for all the major operating systems (Linux, MacOSX, Windows) using libdbus I have been expecting
that any errors the reference implementation has will be fixed over time. Stable multithreading
would be of course a property of libdbus which is of paramount importance for a reference
implementation in todays multithreaded world.

Hence, it appears to be a little bit spooky for me if some expert like Simon (probably knowing the
in and outs of libdbus like his pocket) states along the lines that [my words, not Simon's] how
libdbus does multithreading is not really comprehensible, hence fixing multithreading issues might
cause working multithreaded programs to fail, hence not daring to fix multithreading issues in the
official reference (!) implementation. (Cf. the "executive summary" above.)

As long as GDBus is not the official reference implementation for DBus being available on all major
operating systems (including Windows and MacOSX), I feel forced to stick to libdbus, which is the
official reference implementaiton AFAIK hence expecting it to be stable and reliable, including
libdbus' multithreading, in short::being maintained.

Or am I seeing the case in question wrong or incomplete or skewed?

---rony