I remember when at one time Chris Provenzano said something about
people wanting one thousand threads in one application. The kernel
can't cope with that number of threads very nicely, he proposes to use
a number of kernel threads (ie, our clone() created threads) and then
keep a pool of his userlevel threads to do the work.
This is from Theo de Raadt (deraadt@openbsd.org), commenting on a
question I had:
> > I have
> > the impression that pthreads may assume just one kernel thread, is
> > this the case?
>
> the free pthreads code is userland only. There's 3 ways to do threads.
>
> 1) single process, using setjmp() and timers and wrappers for read()
> and such.
>
> 2) rfork() each thread, and write mutex code. this has the obvious
> problem that processes are too heavy weight. Solution? DUAL-level
> scheduling.
>
> 3) solaris way. You have a bag of kernel threads, and whenever a
> system call happens you merrily squirrel away into a different
> kernel thread. When you return you have code to get you back to
> the right userland thread. I think David can describe this better.
>
> 3 is nicest, but has some nasty problems when adapted to a kernel.
> 2 is easy, but there's no dual-scheduling code at all.
> 1 is what we have today, and might be possibly changeable into 2.
Best wishes,
Miguel.