Dbus in Multi-threaded application

Simon McVittie smcv at collabora.com
Mon Sep 11 12:12:52 UTC 2017

On Sat, 09 Sep 2017 at 17:45:04 +0000, Abhi Arora wrote:
> Do I need to call dbus_threads_init()?

Only if you intend to support dbus < 1.8. In 1.8.0 and newer versions,
it's automatically called when needed.

> As far as I have gone through dbus source code, I think dbus_message_* API
> should be thread-safe and re-entrant.

Passing ownership of a DBusMessage between threads with dbus_message_ref()
and dbus_message_unref() is meant to be safe. At any given time, for any
given message, you should be able to point to one thread and say "this
thread currently owns this message".

Working with the same DBusMessage from more than one thread at the same
time is probably not safe.

The same goes for pending call objects.

DBusConnection is *meant to be* safe to share between threads, but we are
reasonably sure there are bugs in doing that, so it's safest to assume that
it is "owned" by one thread and should not be touched by other threads.

> // Called periodically by glib in  Thread A.

In a good multi-threaded design you should never need to have code that
periodically polls to see whether it needs to do more work. If you're
already using GLib and its "main context" model, then you have all the
necessary tools to pass work between threads without polling.

g_main_context_invoke() or g_main_context_invoke_full(), or in older code
the combination of g_idle_source_new() and g_source_attach(), let you
schedule a function to be called in another thread.


More information about the dbus mailing list