DBus Threading in a Late-loading module

[Havoc Pennington]

Thiago Macieira wrote:
> What I am trying to point out is that we're telling library and plugin 
> developers that they are only allowed to use D-Bus if they are certain 
> that the application is using one D-Bus binding. That sounds rather 
> unacceptable to me.
> 

What else can we do, though? The timeout/watch callbacks aren't global 
just due to some API design mistake, they are inherently global; it only 
makes sense _conceptually_ for one piece of code to block on a given fd 
or install a given timeout.

libdbus can't be the one piece of code, because libdbus doesn't know 
anything about the main loop in use. So it has to punt this to some 
higher layer.

The various dbus bindings could agree on some shared code to install 
these callbacks, but that library would need to choose some main loop to 
use. There's no "main loop independent" way to create a timeout, right?

The only thing I can think of that libdbus could do is document some 
semantics about how dispatch will be done by whatever main loop is in 
charge, perhaps...

?

It certainly is not easy to mix multiple "frameworks" like GTK and Qt 
right now; the exact same problem we're talking about for DBusConnection 
was recently discussed on gtk-devel-list with respect to the X display. 
GDK effectively forms a "binding" for the X display, and someone was 
attempting to allow both GTK and Qt to use the same Display*.

I'm certainly open to fixing this but I'm not sure what we can do.

Havoc