[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: notifications

From: Bas Wijnen
Subject: Re: notifications
Date: Thu, 07 Oct 2004 19:45:46 +0200
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)

Marcus Brinkmann wrote:
Better: It can not send a message to A because there is no
request to reply to.

I don't like to use the word "reply", because it suggests (to me at least) that the IPC is started as a direct result of the request. For A it looks like a reply of course, but for task it's just an IPC.

This is not true.  A server will never do IPC to random tasks just for
the fun of it.  We are talking about an RPC context here.  At least
this is my underlying assumption.  If you want a different IPC
context, you need to define it.

For RPC, I expect the remote procedure to send the reply. This is not the case here, so it is not a reply from the RPC. However, the client doesn't care much, and may as well consider it an RPC anyway.

The server is free to break up the request and reply phase, stash away
the information from the RPC and reply at a later time.

So we are in fact talking about the same thing, only I wouldn't really call it a reply if it's not done by the worker thread which accepted the call.

However, this
is currently unsupported (it requires a bit of extra work because the
L4 kernel needs to know about it when the replying thread changes via
ipc propagation).

I thought they all replied with VirtualSender set to the manager thread? I don't see any problems in that case, but perhaps we're not talking about the same thing.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]