Fwd: Re: Race condition in send_with_reply_and_block()

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Jul 23 05:47:55 PDT 2013


On 22/07/13 20:35, rony wrote:
> A few years ago, studying the DBus specifications I have come to believe that libdbus is the
> official reference implementation, not GDBus

libdbus is the reference implementation. That means that if its
interpretation of the D-Bus Specification conflicts with (for instance)
GDBus' interpretation, libdbus is probably right; but that's all that
being a reference implementation implies. It does not mean it is the
fastest or highest-quality implementation, the easiest-to-develop-with
implementation, or the implementation that interacts best with other
system features (such as multi-threading or various main loops).

> I have been expecting
> that any errors the reference implementation has will be fixed over time.

Errors will only be fixed if someone fixes them. All of the D-Bus
maintainers primarily work on other things, and have a limited amount of
time we can spend on it - in an ideal world, we'd be able to devote a
lot of time to making libdbus perfect, but this is not an ideal world.
My assessment is that we could spend a massive amount of time on trying
to perfect multi-threading and still not get there, so I would prefer to
spend my D-Bus time fixing things that have a better "return on investment".

> how
> libdbus does multithreading is not really comprehensible

Adding correct multi-threading to code that has not been designed for
multi-threading "from the ground up" is rarely comprehensible - this is
not unique to libdbus. :-)

> 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

Please do not feel forced to stick to libdbus. Being the *reference*
implementation does not mean that it is the *best* implementation.

    S



More information about the dbus mailing list