DBus Threading in a Late-loading module

[Thiago Macieira]

nf2 wrote:
>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/

I've told you on IRC: I don't believe that to be true.

I know the reaction KDE developers would have to a proposal of making glib 
mandatory. Regardless of the technical benefits and drawbacks, that would 
be a heated discussion.

Let's not get into that.

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

There's no doc for that because there is no API. In perfect Qt-style API, 
everything is handled behind the scenes for you. No extra library is 
exposed in the front-end API.

QtDBus is like that to libdbus-1.

>> 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);

We can call that dbus_connection_set_watch_functions_if_unset() :-)

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

Or that. We then make it mandatory that anything calling those functions 
can never be unloaded from RAM. Which is a good thing.

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

Some versions of glib had a cumulative performance degradation due to Qt 
timers -- which are used extensively. I profiled a section of glib that 
spent a great deal of the CPU time in a tight while loop searching for 
the proper position (generally, the end) of a singly-linked list.

Since Qt-based applications create and destroy timers a lot, that proved 
to be a bottleneck.

We're going off-topic...

-- 
  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/20070405/51970508/attachment.pgp