Call serials and async call handling (Was: D-BUS in KDE)

[Waldo Bastian]

On Sunday 03 October 2004 00:53, Havoc Pennington wrote:
>  - when making a method call, if the call serial were globally unique,
>    we could forward the call serial along with any method calls made
>    as a result of the first method call, and allow reentrancy that was
>    strictly part of the call stack of said method call. But I don't
>    really see how to do this without making the user pass around the
>    call serial to all method calls all the time, or disallowing
>    async calls.
>
>    If done post 1.0 will probably be an optional/ugly-API type
>    of thing.
>
> By "optional/ugly" what I mean is something like, right now we have
> new_reply() for sending a method call reply, we could add a
> new_reply_with_call_serial() that took the unique number.
>
> The optional/ugly aspect would not impact bindings such as the Qt
> bindings since they could probably handle it automatically.
> The whole low-level libdbus is ugly anyhow so it's sort of irrelevant.

Yes, DCOP is oriented towards in-sync call handling in which case DCOP can 
keep track of the call serial. In the async case that will no longer work and 
the application will indeed need to keep track of the call serial itself 
since only the application will know which call it is actually handling.
I even suspect that this is actually missing in DCOP at the moment.

That's only an issue if you do outgoing calls as a result of an incoming call 
that you handle async. For async call handling the application will anyway 
need to keep track of some context that identifies the incoming call (it will 
need to identify the call when it sends back the reply) so maybe it can pass 
along that same context when doing outgoing calls. 

The API I am thinking of is something like a function call that says to dbus 
"I (this thread) am (is) now handling this incoming call", that way you don't 
have to explicitly pass the context to the outgoing call, which may be a 
problem because the actual call could be done as part of some library 
function.

Cheers,
Waldo
-- 
bastian at kde.org  |  Wanted: Talented KDE developer  |  bastian at suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041003/7051d4df/attachment.sig>