The deadlocks [was: Announcing new version of the Qt4 bindings]

Thiago Macieira thiago.macieira at
Tue Feb 14 10:47:28 PST 2006

Thiago Macieira wrote:
>I think I can solve this inside the binding without need for anything
>special inside libdbus. I'll let you know in a while if my idea worked.
>Currently, the process stack goes like this:
>event loop -> socket notifier -> dbus_connection_dispatch -> filter ->
>user function
>If the user function recurses into another loop, it'll try to acquire
> the dispatcher again and deadlock (since the mutex is non-reentrant).
>My solution will be to rely on the behaviour that
> dbus_connection_dispatch pops never more than one message from the
> input queue. That way, we'll have:
>event loop -> socket notifier -> dbus_connection_dispatch -> filter
>The filter will just prepare the call, but not execute it. When
>dbus_connection_dispatch exits, the socket notifier code will realise
>there's a pending call to be delivered and will deliver from there. This
>way, the DBus dispatcher will be unlocked for further calls.

This is just to let you guys know that the idea worked.

When the filter is invoked from dbus_connection_dispatch, it verifies 
whether the message is one that it can handle. If it is, it'll prepare 
the call but not actually make it. Then we return HANDLED to the 

When dbus_connection_dispatch returns, we execute the calls that were 
prepared. This has now allowed for unlimited reentrancy inside Qt-based 

However, this also means that the Qt bindings are uncooperative to anyone 
else using the same DBusConnection. If our filter is run while another 
function called dbus_connection_dispatch, we could end up queueing calls 
that may never be executed.

Thiago José Macieira - thiago.macieira AT
Trolltech AS - Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the dbus mailing list