Re: L4Mach or Refactor Hurd Servers?

[Espen Skoglund]

[Farid Hajji]
>> Personally, I find it very appealing to be able to perform
>> *arbitrary* i/o or i/o-like operations by sending asyncronous
>> messages, and then being able to wait on a collection of reply
>> ports until one of the operations returns or times out. I guess one
>> reason I like that way of operation is memories of the AmigaOS.

> Under L4, you'll have to do this in user-land, e.g. using a message
> task server that buffers the i/o. Of course, you'll have to take
> into account more context switches, and most of the time, copying or
> at least page transfers.

> This is not very efficient, therefore it should be reserved for rare
> situations. Most of the IPC should be synchroneous, if we want to
> get a reasonably fast OS running on top of L4. If seldom situations
> require buffering the messages (or, btw, using some notification
> server for no-senders etc...), so be it. We are not forced to
> over-optimize seldom used code [then again, no-one profiled the Hurd
> yet, so we can't tell for sure what occurs often and what not].

> This all boils down to this: You can use any kind of I/O, including
> asynch. message. Doing this comes at a performance price however.

If you want to implement some "message buffer server" which handles
the async IPC, however, you should remember that this server can be
located in the same address space as the receiver (or sender).  As
such, the overhead needed by going through the message server only
requires an intra-task IPC.  Fortunately, (some) intra-task IPC can be
implemented without any user-kernel switching and is therefore fast on
all kinds of CPUs (think ~15 cycles on x86).  That said, async IPC
should be avoided whenever possible since it still requires some
overhead and is not completely transparent to the users of the IPC
mecahnism.

        eSk