The deadlocks [was: Announcing new version of the Qt4 bindings]
thiago.macieira at trolltech.com
Wed Feb 15 06:33:55 PST 2006
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
- every time our event filter gets run, we check if the message can be
- 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
>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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060215/3d5383ed/attachment.pgp
More information about the dbus