thread safety: connections and mainloops
walters at verbum.org
Thu Jul 28 01:43:36 EST 2005
On Mon, 2005-07-25 at 16:23 -0400, Havoc Pennington wrote:
> The intent of dbus_bus_get() is to share the connection (have a global
> connection object), sort of like the global gdk_display in GTK. This way
> every code module doesn't have to create its own socket.
Yeah, I understand that. The patch was intended to at least keep it to
one socket etc per binding.
> Note that dbus_connection_open() _also_ returns shared connections, but
> there's a dbus_connection_open_private() to avoid them.
Ah. That would be the source of the current issue I'm seeing then.
> If the thread model were one-thread-per-connection, then none of the
> locking hell in dbus-connection.c would be required. The thread safety
> is intended to be multiple threads accessing a single connection.
> Typically you'd use multiple threads _without_ a main loop... just use
> blocking IO. That's the point of threads after all.
The implication here is that using dbus_g_proxy_begin_call (or
dbus_connection_send_with_reply) from a thread is not supported and you
have to do dbus_g_proxy_call (dbus_connection_send_with_reply_and_block)
for every invocation, right? If we don't support thread mainloops I
don't see how it could work, since callbacks would run from the main
Maybe this isn't such a serious limitation; since the GLib bindings have
a nice asynchronous interface I imagine most application writers will
use that. What I'm most concerned about is an application writer using
a big library in a separate thread which non-obviously depends on DBus;
imagine for example a GStreamer output plugin which used HAL to find
output sound cards or something and used the asynchronous GLib
If we wanted to support this, I guess the fix would be to add a
GMainContext initialization argument to any GLib-oriented library which
uses an asynchronous interface internally and make sure that works,
including the DBus GLib bindings.
I should note that what you're basically advocating above is
thread-per-task, instead of thread-per-subsystem, but not all
applications do things that way. For example NetworkManager has a
thread per network device. I'm not sure whether it actually wants to
use DBus from the device threads...but I don't think it would be
entirely crazy to e.g. query HAL from them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050727/c5dce404/attachment.pgp
More information about the dbus