RE: L4Mach or Refactor Hurd Servers?

[Volkmar Uhlig]

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

This depends on two things -- first, the costs per thread and second, if
you _really_ need two threads or if you potentially could use the second
thread for multiple open-file threads. 

Btw, using one thread per file may be also quite impractical with a
kernel like MACH. In L4 we currently need 1K per TCB. I would expect
that MACH's TCB is at least two times as big if not more...

-- Volkmar