DBus Threading in a Late-loading module
hp at redhat.com
Sun Apr 1 21:44:41 PDT 2007
Nate Nielsen wrote:
> However, if the module was loaded/initialized late in a process's
> execution, and any DBus communication elsewhere in the process was
> already underway, calling dbus_threads_init_default() would probably
> cause problems, no?
It would, yup.
> If I limit each DBusConnection to strictly one thread and lock
> appropriately, will DBus be threadsafe even without calling
This won't work, because there are global variables that need to be
locked. Without the init_default they won't be locked.
> I'm not looking for a 'get-out-of-jail-free' card :) Just evaluating
> DBus as an IPC mechanism for this particular use.
Essentially you'd have to require any app using your lib to init dbus
thread locking. gnome-vfs may already require this though (not sure), so
the requirement might be fine for gnome-keyring also.
btw, do be careful with private connections - or at least look at the
size of the DBusConnection struct in dbus-connection.c first ;-) and
remember there's an extra file descriptor and so forth as well. It's not
like it's incredibly expensive, but it should certainly be avoided if at
all possible for any library that "many" or "most" apps in a typical
desktop session will be using, since the cost will be multiplied by
number of apps.
I assume in this case the communication channel needs to disallow
eavesdropping from other apps and that's why it's private?
If this is the only reason for the private connection, it would also be
possible to do this by installing security policy rules for the session
bus, similar to how it's done for the system bus. Unfortunately we don't
have a "session.d" directory in the default session.conf right now, but
it's a one line patch to add if there's a use case like this.
Part of the reason for the bus daemon is to allow N apps to communicate
with N network connections, rather than whatever combinatorial explosion
it would be otherwise.
More information about the dbus