dbus-glib, GLib and threads

[Simon McVittie]

On 26/07/12 06:49, Alberto Mardegan wrote:
> a multithreaded application [...] written using dbus-glib

The short answer is "don't". libdbus attempts to be thread-safe, but
dbus-glib does not go to any particular efforts to be thread-safe.

(libdbus was not thread-safe until 1.6 anyway, due to flaws in its
recursive mutex implementation, which can't have helped.)

> 1) Don't use a global singleton: call g_thread_self() in the SignonProxy
> constructor to create a singleton object per each thread.
> 2) Call dbus_g_bus_get_private(), not dbus_g_bus_get()

You can also expect to have to track down trivial race conditions
throughout dbus-glib, and possibly some more subtle ones in libdbus too.
Have your thread-debugging tools like helgrind ready.

I would recommend either porting to GDBus as soon as possible, or doing
all your dbus-glib usage in the main thread. If you need to do D-Bus
things from non-main threads, submit messages to the main thread in a
thread-safe way (e.g. scheduling a GLib idle to run there) and have the
main thread submit messages back to you (e.g. scheduling an idle in your
other thread's main context).

I would estimate that the development effort necessary to make dbus-glib
thread-safe exceeds the development effort necessary to port a typical
project to GDBus.

    S