Re: L4Mach or Refactor Hurd Servers?

[Farid Hajji]

[Triming Cc: to roland and l4-hurd only]

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

> So I think it wuld be said to throw away the support for that
> entirely, but there may well be some nice way to do it on the library
> level (in the client's process) by using a syncronous RPC-interface
> and some extra threads.
Yes, that is the obvious hack: using a message task that is accessed
by libraries linked in client space. The general question is wether
it is necessary to use asynch IPC most of the time.

> Please keep in mind the case of calling select() or poll() on a few
> thousands of file descriptors, you want to support that without
> spawning an insane amount of threads.
As Ian pointed out, senders simply block until the receiver[-thread]
sequentially proceeses the requests. I'm afraid that large number
of threads is inevitable in OSes that consider each (open) file
a "connection."

> Regards,
> /Niels

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.