DBus Threading in a Late-loading module

[Havoc Pennington]

Thiago Macieira wrote:
> That was about DBusWatch and DBusTimeout, but it applies somewhat to 
> threading too. In fact, if we solve the problem of the mainloop 
> integration, we solve the problem of threading too.
> 

I mentioned this offhand in the "DBusConnection -> DBusGConnection" 
thread. Right now, essentially all libraries and app code in the same 
address space have to agree on the global libdbus configuration: thread 
setup, watch and timeout handling, etc.

The original idea here was that all gtk apps would pretty much assume 
that the glib bindings were in use, and all qt apps would pretty much 
assume the qt bindings were in use.

I think that's fine, except for the case where someone wants to write a 
library or plugin or something that works with both gtk and qt apps. I 
think in those cases there are a couple of options:
  - make the library or plugin *also* have a configurable main loop (I
    guess we're already seeing this e.g. in dbus-python)
  - some kind of shared main loop library used by both GLib and Qt ?

For threads, the problem is pretty easy to solve: have all the bindings 
use init_default() and not their own thread systems. This is because 
there isn't really a reason that all thread locks in an app have to use 
GThread or QThread.

For the main loop stuff, it isn't that easy, since exporting a default 
main loop abstraction from dbus isn't appealing. And all main-loop-users 
in an app *do* need to agree on the main loop implementation - the app 
can only block in one loop.

So I would see the main loop (watch/timeout) stuff as something libdbus 
itself can't really solve, it has to be solved in a more global way.

Havoc