implementing IN_PROGRESS

[Thiago Macieira]

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 
return HANDLED, NOT_HANDLED and (new one) PARTIALLY_HANDLED.
* 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 
decide.

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

-- 
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/ceca9fe3/attachment.pgp