DBus Threading in a Late-loading module
hp at redhat.com
Mon Apr 2 10:45:06 PDT 2007
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.
More information about the dbus