DBus Threading in a Late-loading module

[nf2]

Thiago Macieira wrote:
> 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.
>   
I believe that glib main loop integration should be default for KDE on 
unixes anyway, because it would be a lot easier to write asynchronous 
common infrastructure libraries.*) But i know that a lot of KDE 
developers don't like that idea. ;-)

*) http://www.scheinwelt.at/~norbertf/common_main_loop/

Btw, is there any API doc for Qt's glib main loop integration?

> 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.
>   
Yes - that seems to be a problem - perhaps every binding should look if 
a dbus connection is already hooked into a main loop, and only call 
dbus_connection_set_watch_functions() and 
dbus_connection_set_timeout_functions() if it's not.

Perhaps there should be a function to query whether watch/timeout 
functions have already been hooked for a connection:

dbus_bool_t 
dbus_connection_has_watch_and_timout_functions(DBusConnection * connection);

Another option would be to simply let 
dbus_connection_set_watch_functions() and 
dbus_connection_set_timeout_functions() fail if they are called a second 
time...

>
> 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.
>
>   

Hmm - what's the problem with this?

norbert