Quoth Jonathan Cast :
...
| Say what? This discussion is entirely about performance --- does
| CPython actually have the ability to scale concurrent programs to
| multiple processors?
Well, ostensibly the discussion also has something to do with Haskell.
On that premise, may I say I hope we're not inspired by Python's example
to treat concurrency as a religious matter.
The C Python community is forced to take the position that interpreter-
level threading is not worth the price, because they don't have it and
can't conveniently get it. I doubt we'll ever know for sure whether
they're right or wrong, since Python comes with other issues that could
also take blame or credit for its success at large scale applications.
The Haskell community seems to be convinced as a whole that user-level
threads are the way to go, but at most that's just a majority, not a
consensus. Who cares!? Given the ability to take either path, Haskell
programmers will solve our religious argument - we'll know who gets to
heaven with working, high performance, reliable applications.
That is, assuming that programmers of each persuasion can find Haskell
suited to their model. As far as I know, though, that isn't a really
sure thing. I've read things like "thread RTS can't/shouldn't support fork"
and "would like to be able to get rid of the non-threaded RTS", with
respect to GHC.
At least until there is more empirical evidence that it's a waste of time,
Haskell implementations should leave this to the programmer - support
processes, OS threads, or user threads without undue work-around burdens.
Otherwise we'll be stuck like the Python community is, defending this
approach as a religious argument. We have enough of those already.
Donn Cave, donn@avvanta.com
