Re: L4Mach or Refactor Hurd Servers?

[Niels Möller]

Farid Hajji <address@hidden> writes:

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

I'm not sure you got my point: The current Hurd select rpc can't be
used as a (single) syncronous rpc. To convert it to a syncrounos
ipc-model like L4's, you have to butcher it up into two syncronous
rpc:s, perhaps modelled after the file notification rpc:s,
file_notice_changes, file_changed.

Perhaps my terminology is a little confused. The problem is not the
syncronicity itself, if that just means that the kernel doesn't do
buffering. The problem is that a single rpc call is used to both send
a request _and_ get the reply to it.

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

I think it is wrong to force threading on applications. That Hurd
fileservers use one thread per open file is one thing. Saying that
filesystem _clients_ must also have one thread per open file (whether
they spawn threads explicitly or libc does that for them) is a
different matter. Having one thread per open file _somewhere_ in the
system makes some sense. But I'd say that requiring _two_ threads for
each open file, one on each side of the rpc interface, indicates a
problem with the design.

Regards,
/Niels