Need help understanding dbus-glib event loop

[Schmottlach, Glenn]

> libdbus, the lower-level library used by dbus-glib, QtDBus etc., is likely to
> be more thread-safe (various people have contributed thread-safety fixes to it,
> I believe).

My experience has been quite the contrary. Perhaps I don't have all the necessary patches applied to ensure complete thread-safety but at one time the asynchronous (pending call) API was basically broken from a thread-safety standpoint (e.g. it had a bad race condition). It was ever sufficiently addressed for my tastes.

For me, the most successful approach has been to isolate the D-Bus main-loop (thread) from the rest of the system. All D-Bus calls should be made from this thread which subsequently makes the application appear as a single-threaded implementation (from the perspective of D-Bus). D-Bus requests issued from other threads are marshaled through some sort of barrier (queue) and dispatched from the main-loop. An internal pipe's file-descriptor can be monitored by the main-loop and used to detect when there is a new command to dispatch (rather than polling the queue). Basically, when you add a command to the "work" queue you write a byte to the pipe to "wake-up" the D-Bus main-loop. A "watch" handler deques the command and invokes the D-Bus method call. Incoming signals are delivered by the D-Bus main-loop to other threads so appropriate synchronization is necessary between these threads. 

Most users of D-Bus are GUI applications with the main-loop already baked into the GUI framework (QT, GLIB/GTK). It's a reactive system with button-clicks eventually invoking asynchronous D-Bus calls. Typically these applications are single threaded. That's the environment where D-Bus works best. Move it outside that comfort zone and things become more difficult . . . not impossible . . . but difficult.