thread safety: connections and mainloops

[Colin Walters]

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
thread, no?

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
interface.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050727/c5dce404/attachment.pgp