DBus Threading in a Late-loading module

[Thiago Macieira]

nf2 wrote:
>Thiago Macieira wrote:
>> Havoc Pennington wrote:
>>> There's just no way this can work AFAIK unless Qt and GLib in fact
>>> use the same main loop. And then there should be no problem with
>>> dbus, right?
>>
>> The mainloop isn't enough: the functions handling watches and timeouts
>> are.
>>
>> There's a thin layer of code between libdbus and the toolkit that
>> handles that, including a mapping of the structures.
>
>I thought Qt>=4.2 can use glib main loop
>(http://doc.trolltech.com/4.2/qt4-2-intro.html). Thus watches and timers
>should work, no matter if they are registered with the Qt API or the
>glib main loop API... (because the Qt mainloop API just wraps glib main
>loop)

It can, but you misunderstand the problem. And this is not mentioning that 
the glib main loop integration is optional and can be disabled at 
runtime.

libdbus has two structures called DBusWatch and DBusTimeout. The bindings 
are required to keep a mapping of those structures to their own 
representations of timers and file-descriptor pollings. This glue is what 
breaks if you have two bindings running in the same application -- or 
none.

Even if an application using QtDBus is indirectly using glib's own 
structures (GSources for polls and timeouts), QtDBus doesn't know 
anything about them: all it knows are the Qt equivalents (QSocketNotifier 
and QObject timers). If a second binding were to re-initialise the 
callback functions, the old associations would be lost and behaviour 
would be unpredictable.

If no binding associates said functions, libdbus may simply not work 
(again, unpredictable behaviour).

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.

PS: as an implementation detail, all Qt timers are handled by a single 
glib timeout GSource, so there's not even a direct 1-to-1 object mapping.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070403/86d1847c/attachment.pgp