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

[Thiago Macieira]

Havoc Pennington wrote:
>On Tue, 2006-02-14 at 19:47 +0100, Thiago Macieira wrote:
>> 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.
>
>Can you explain this scenario a bit more? I don't fully understand what
>happens in this case, I'd like to think about how we could address it.

I've rearranged the code a bit. Instead of doing the way I was doing, 
here's what it does now:

- select(2) detects activity in the socket
- we call dbus_connection_dispatch for as long as it returns
 DBUS_DISPATCH_DATA_REMAINS
- every time our event filter gets run, we check if the message can be
  handled
  - if it can be handled, we post an event to ourselves and return saying
    we've handled it
  - if not, we tell we couldn't handle it

When the event loop is run again, we deliver the calls.

However, if something else runs dbus_connection_dispatch, we'll queue 
calls that won't be delivered until the next event loop iteration. Since 
we currently don't support any other kind of event loop other than our 
own, it's not a problem. 

When we do, I'll probably switch to using dbus_bus_get_private. Our object 
tree is populated on the fly, not using 
dbus_connection_register_object_path.

>Would the IN_PROGRESS dispatch status help? (so you would not queue up
>things yourself, the dbus connection would just keep things in the queue
>until dispatch was called non-recursively...)

Yes, that would help. Maybe even better than our current solution, because 
it does create arbitrary reentrancy. And it would be a lot cleaner, 
because it wouldn't involve mutex locks to post events to the event loop 
and the possibility of other stuff having been run in the meantime.

In my test case, whenever a signal was delivered, we made a call to HAL. 
But HAL delivers the same signal 3 times, for whatever reason, so we made 
3 calls. The end result is that the signal handler recurses.

But that's to be expected, since the contract is now that any call to 
D-Bus can cause reentrancy anywhere in the D-Bus visible code.

-- 
Thiago José Macieira - thiago.macieira AT trolltech.com
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 : http://lists.freedesktop.org/archives/dbus/attachments/20060215/3d5383ed/attachment.pgp