Simon Peyton-Jones wrote:
[...] GHC's approach to threading [...] The current GHC model has the basic assumption that OS threads are inter-changeable.
As has already been mentioned by others, this assumption doesn't hold if you leave the Happy World of Haskell(tm): Locks/mutexes/... and thread-local variables can be hidden under the hoods of many libraries out there, for which there will *never* be a Haskell replacement. I consider the ability to write bindings to those libraries as an extremely important point, otherwise the usefulness of Haskell is rather limited. Remember that Haskell has been described as a "good glue" for other building blocks (= APIs) around...
[...] There is a good reason for this: the current OS thread may block in some I/O call (getChar, say), and we don't want that to block all Haskell threads.
Hmmm, I don't consider this a good reason. IMHO there are basically 2 ways for threading in an RTS: * The "Green Threads" approach, where no OS threading is used, but everything is done by hand, 'select'-ing carefully internally, etc. If the user itself calls out to C land and gets blocked, the whole RTS is blocked. Not nice, but the price to pay for getting flyweight threads. * A 1-1 mapping from the threads in the language in question to OS threads. If there is a danger of blocking, the user forks away a new thread to do the work, and everything is fine. The Java world lives quite happily with this. Anything between will be doomed to fail in the general case, I fear, for the reasons given in this (mail- :-) thread. It is OK if no external code is ever called, but then you may use "Green Threads", anyway... Hacking GLUT to work with GHC's current approach makes no sense, it would only solve a single instance of a general problem. Furthermore, it would be extremely system-dependent and would cost a *vast* amount of performance: Switching OpenGL contexts can require a round-trip to a remote server, can trigger swapping a few MB of textures into your favourite graphics card, etc. OK, these are worst-case scenarios, but doing even the best case just for drawing a few vertices would probably be ridiculously slow. Cheers, S.