> Simple: use a library wrapper like a standard user-mode threading
> package, and use a pool of kernel threads to schedule between.
>
> And this is completely broken, even though this is what all the
> various unix vendors do.
>
> There should be one kernel clone thread per user thread, with no
> exceptions.
(...)
> Linux can schedule, create, and destroy clone threads nearly as fast
> as any user level scheme could, therefore there is really no gain in
> this scheme, only added complexity.
What about memory consumption? What about file descriptor consumption?
Aren't (clone<->library)-multiplexed threads more system-friendly in this
regard? I recall Larry pointing this out the other day advising an
individual not to write a thousand-thread windowing system.
I'm far from an expert on the topic, but to say that the kernel-based
solution is the only way to go and then to reccommend against threading
because of the costs which result from basing it on clone() seems a tad
unsightly to me.
__
Todd Graham Lewis MindSpring Enterprises tlewis@mindspring.com