implementing IN_PROGRESS

Thiago Macieira thiago.macieira at
Sat Feb 25 12:40:31 PST 2006

Havoc Pennington wrote:
>Other suggestions?

Is this part of the solution to the library->binding->usercode->library 
recursion we talked about earlier?

If so, the solution I had considered was much simpler:

* no modification to the dispatch lock
* when calling to user (binding) code, the binding has the option to 
* when receiving a PARTIALLY_HANDLED return code, the code would pop the 
message from the queue just as if it had been fully handled and place it 
in a new queue, allocated on the stack, local to the function.
* after all other locks have been released, call the binding again for all 
the PARTIALLY_HANDLED messages. There is no return code: the binding MUST 
handle it fully.

Whether the function to be called for the second time is the same one or a 
new one for the message filters / object handlers I leave it for you to 

This makes the solution completely ABI/API compatible for existing code, 
since they won't enter the new codepath because they will never return 

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: 191 bytes
Desc: not available
Url :

More information about the dbus mailing list