Hmm. Makes sense to me. All it is saying is that you can't make a good
dinner out of a pile of salt. It was originally said to some GUI people
who wanted to use a thread per object, every button, scrollbar, canvas,
text widget, menu, etc., are all threads. What they didn't figure out is
that a thread needs a stack, the stack is the dominating space term, and
they were looking at a typical desktop with around 9,000 objects. Times,
at that point, an 8K stack. That was 73MB in stacks. Pretty darned stupid
when you look at it that way, huh?
Nobody is arguing that having more than one thread of execution in an
application is a bad idea. On an SMP machine, having the same number of
processes/threads as there are CPUs is a requirement to get the scaling
if that app is all you are running. That's fine. But on a uniprocessor,
threads are basically stupid. The only place that I know of where it is
necessary is for I/O which blocks. And even there you only need enough
to overlap the I/O such that it streams. And processes will, and do,
work fine for that.
I think the general thrust of us ``anti-thread'' people is that a few
are fine, a lot is stupid, and the model encourages a lot. It's just
like perl5, C++, pick-your-favorite-feature-rich-language in that
exceptional programmers will do a good job with the problem but average
programmers will do a horrible job. Given that there are only a few
exceptional programmers and a never ending wave of average programmers,
the argument is that one should tailor the paradigm for the common case,
not for the exceptional case.
----- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/