Re: notifications

[Bas Wijnen]

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.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature