implementing IN_PROGRESS

[Thiago Macieira]

Havoc Pennington wrote:
>Here's the "normal case":
>
>   BindingMainLoopIterate
>     calls dbus_connection_dispatch (TAKES DISPATCH LOCK)
>       calls binding code to handle a message
>         calls application code associated with the message
>     (DROPS DISPATCH LOCK)
>   BindingMainLoopIterate
>     ... repeats

Ok.

>Here's the bug:
>
>   BindingMainLoopIterate
>     calls dbus_connection_dispatch (TAKES DISPATCH LOCK)
>       calls binding code to handle a message
>         calls application code associated with the message
>           calls BindingMainLoopIterate [1]
>             calls dbus_connection_dispatch (DEADLOCKS ON DISPATCH LOCK)

Yes, that's the problem.

>I understand you to be saying:
>
>   BindingMainLoopIterate
>     calls dbus_connection_dispatch (TAKES DISPATCH LOCK)
>       calls binding code to handle a message (SAVES A RECURSION FLAG)
>         calls application code associated with the message
>           calls BindingMainLoopIterate [1]
>             calls dbus_connection_dispatch or similar
>               calls binding to handle a message
>                 returns PARTIALLY_HANDLED since recursion flag set
>               waits for dispatch lock to be dropped [2]
>               calls binding to handle PARTIALLY_HANDLED messages

No. I want to do it like this:

   BindingMainLoopIterate
     calls dbus_connection_dispatch (TAKES DISPATCH LOCK)
       acquire locks
       for each message in connection queue:
         calls binding code to handle a message
           checks if it's a call we will handle
           if so, return PARTIALLY_HANDLED; if not, return NOT_HANDLED
         if NOT_HANDLED, generate UnknownMethod error
         if PARTIALLY_HANDLED, add to local queue
       repeat
       release locks
       for each message in local queue:
         calls binding code to handle partially-handled message
           calls application code associated with the message
             calls BindingMainLoopIterate
               calls dbus_connection_dispatch
                 acquire locks <-- this works, because no locks 
                                   are being held
                 [...]

This is the solution I have currently implemented. The difference is that 
the "local queue" is in fact the Main Event Loop: when I tell 
dbus_connection_dispatch that I've handled the message, I have not called 
any user code yet. User code will be called when control returns to the 
event loop.

If I understand your solution correctly, it won't solve my problem. The 
reason the main loop is reentered is because we *want* to handle a new 
message.

The concrete example of what my user is doing is:
- connects signal from Hal to his application
- in his signal handler, he makes a *blocking* call to Hal again

-- 
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: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060225/096c1137/attachment.pgp