>> i don't see how csp is *not* parallel processing. as soon
>> as you have more than 1 work process per client, i would call
>> that parallel processing.
>
> It's a kind of parallelism, of course. But since it makes sense, it is
> not "parallelism" as the trend is today ;)
I don't know what the trend is today. If the trend is defined by what
Linux does then I'm not very curious.
The point of the Plan 9 thread library was — and still is, as far
as I'm concerned — to be a tool that aids in concurrent programming.
I'm explicitly not saying parallel programming. I think of
parallel programming as a technique for finishing some algorithm faster.
I think of concurrent programming as a way of keeping indeterminism
under control. A file server serves many customers simultaneously,
and must expect requests, disk events, etc. to happen in any order.
Managing this is what Plan 9 threaded programs are good at.
And our model of using channels for interthread and interprocess
communication, while using a thread pool (all in one proc) for managing
shared data without needing locks, is the best programming model for
these kinds of programs I've ever come across.
You can write parallel programs using the thread library but that's not
what its primary purpose was and it's probably not going to help you
much.
Sape
