> > Are there any results on the value of
> additional-userland-threads available,
> > mesured in real world scenarios?
>
> Yes. Think "networking server", for example. Something like a NNTP or HTTP
> server can be coded more efficient than with fork()s, and more
> elegant than
> single-threaded+poll()/select()+lots of legwork in the code.

The question was not clear. I didn't mean to ask for the value of
multithreaded userland applications (hey, I'm making my living with doing
heavy multithreaded stuff on NT). Even if its not that clear (or maybe a
matter of taste) wether doing multiple socket IO via select or multiple
blocking threads is easier. I've done both and have found situations where
both lead to quite elegant and simple code.

No, the real question was a kernel implementation issue: do we realy gain
much by doing userland threads in a mixed userland/kernel implementation.
The alternative would be a clever mostly-kernel base implementation (with
only the minimal syscall stubs in userland and thread-safe libraries),
probably using a thread pool (and details probably similiar to the
activation concept), but without having multiple userland threads share the
same kernel thread. "Kernel thread" in this sense only means some kind of
thread handle. The real threads would be limited to the pool, so we don't
end up allocating hundreds of kenrel stacks and contexts.

Noriyuki Soda gave a reference showing numbers, thats what I was looking
for.


Martin