On Tue, Jan 30, 2007 at 01:16:22PM -0800, Kaz Kylheku ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > I described in details why and how M:N model better, and its drawbacks > > include all issues mentioned by Ulrich Drepper, but nevertheless its > > advantages are far too superiour than those which can be > > provided by 1:1 > > model. > > M:N threading is an unnecessary performance hack that's needed by people > who are living in a C or C++ exile away from some language that has > lexical closures, generators or first-class continuations. Not having > these niceties, they resort to emulating them with threads. The proper > thing to do is to rewrite the code to use state machines which can be > driven by any available thread. Or else, write yourself a > source-to-source transformer that will give C the lexical closure, > generator, or continuation features that you need to express the > solution that way. > > There is no need to retain any vestiges of a user space threading > implementation when you have the real thing. > > Programs which appear to benefit from that model are badly optimized or > badly designed. A smartly written program uses an available thread to do > as much work as possible, until that thread happens to block or its time > slice burns up.
Do not mix languages like Erlang, specialy designed for concurrent programming, with M:N threading model - they are completely different, but you do not want to see this. As you pointed, one thread can do as much as it need until it is blocked, and what next? Allocate new real thread? You may want to see how things like JVM work, I seriously doubt spwning new thread each time task blocks is a way to go. Even having epoll does not help in many cases. And you forgot the price of rescheduling in kernelspace and userspace - even with signals it differs two times, with more intellegent case it differs in 20 times! Virtual machine can have thousands of threads, actually it cant, since it will kill Linux in rescheduling. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/