DBus Threading in a Late-loading module

[Havoc Pennington]

Hi,

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
> dbus_threads_init_default()?

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.

Havoc