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