pardon me if I chime in without knowing the implementation details, but I'm an HOpenGL user who tends to like Haskell concurrency (if only we had Erlang-style distribution in the main-ghc line..:). And I do have the feeling that the suggested solutions keep getting more complex, moving away from programming in the language into controlling its implementation. I still like Sven's idea - noone has asked for a new OS thread for the callbacks, so there shouldn't be one, so there shouldn't be a problem with the admittedly not nice use of OS-thread-local storage. The argument against that suggestion was that --enable-threaded-rts explicitly asks ghc to run Haskell threads in >= 2 OS threads, to reduce problems with blocking external calls. That alone still isn't a problem, but the default to run callbacks in a different OS-thread is (so the RTS doesn't seem to manage OS-threads as resources, but allocates them according to a pre-defined scheme that works in many sane situations). Incidentally, while GLUT callbacks are made, the original Haskell thread should be calling out to the GLUT mainloop, which doesn't return, also suggesting that one should reuse that OS thread. Others have suggested a 1-1 correspondence between OS and Haskell threads, but I don't believe that would be a good idea with current OSs. But if you mix all this together, you get another option: - introduce Haskell thread groups (HTG) - a HTG is a collection of Haskell threads that share one OS thread (alternatively, each HTG could have two OS-threads - one for *all* outgoing and incoming external calls, one for internal processing) - add a forkGroup, which starts a new Haskell thread in its own HTG (using different OS-threads is the only difference between Haskell threads in different HTGs) Now, there is no need for the --enable-threaded-rts option: if the Haskell programmer expects problems with blocking external calls, she can simply run several HTGs. There is no problem with OpenGLs peculiarities, as long as callbacks really call back, into the same HTG, that is. This probably needs some additional bookkeeping, to make callbacks HTG/OS-thread-specific. And, best of all, there are fewer low-level controls out of reach of the Haskell program. Of course, there must be disadvantages as well.. Claus