Re: L4Mach or Refactor Hurd Servers?

[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.

2. A typical "Hurd RPC" actually consists of two Mach RPC:s, one for
   the request and another one for the reply. A typical rpc stub
   function, generated by mig, sends a request message and then waits
   for the reply message, hiding the Mach one-way messaging from most
   of the hurd code.

3. When porting to L4, it is natural to make a Hurd RPC (request and
   reply) a single L4 RPC, using the operations you mention. I think
   Farid's comment that the Hurd code needs to be changed to "only use
   syncronous rpc" implied doing exactly that.

I wanted to point out that for a few but important Hurd RPC:s, in
particular select, (3) doesn't work well. It probably has to be two L4
RPC:s.

(BTW, It would make sense to have the first select L4-rpc return an
indication on whether or not i/o can be done "immediately". That would
be an elegant way to solve the select-with-zero-timeout-problem, I
think).

Regards,
/Niels

PS. Furthermore, separate request/response RPC:s are useful for any
single threaded application that wants to do a lot of things without
blocking. That's one of the problems with unix: There are too many
important things an applications needs to do that can't be done in a
non-blocking, asyncronous fashion (and often using threads is no easy
solution either, as alternative thread safe API:s are not always
available, working or portable). I think keeping an alternative
asyncronous API (similar to the separate request/reply stub functions
with mig and Mach) would be a useful thing to have also on L4, but I
understand if that's no high priority. If stub generation is done
right, it should be possible to fix that later by just hacking the IDL
compiler/stub generator.