Re: L4Mach or Refactor Hurd Servers?

[Espen Skoglund]

[Niels Möller]
> Espen Skoglund <address@hidden> writes:
>> I didn't know that this was a limitation of Mach (if it really is).
>> Just for the information, in L4 the following (among other) types
>> of synchronous IPCs are supported:
>> 
>> call (S) -- Send a request to S and wait for a reply from S.
>> 
>> C = reply_and_wait (C) -- Send reply to C and wait for a request
>> from a new C.
>> 
>> Did I miss something here, or is it so that Mach does not support
>> these kind of operations?

> My understanding is that

> 1. In Mach, the basic message send operation is one-way. (It is also
>    buffered by the kernel, but that's peripheral to this
>    argument). I don't think about that as a "limitation", it's just
>    different from L4, and quite natural given that messages are
>    buffered by the kernel.

But it makes RPC operations terribly difficult to implement using
synchronous IPCs.  If one can do a send and receive IPC (call) in one
single system call the kernel can ensure that the sender (client)
atomically will switch from sending to receiving when the request is
received at the other end (at the server).  As such, the server will
know that the client (if behaving correctly) is already waiting to
receive the reply, and can therefore send the reply using a zero
timeout.  If the kernel can give no such guaranties, the server must
in some way make sure that the client is scheduled so that it can
issue the receive operation.

Hmmm.... come to think of it, I think I'm now repeating what you said
two mails ago (I'd better head home now).  Anyways, this problem only
occurs if the kernel only supports synchronous IPCs, so I guess that's
a plausible reason to why Mach doesn't support it.

        eSk