| My proposal is to leave dealing with thread-local state to | the library | binding (in this case, HOpenGL). This requires just a little support | from the RTS. The library binding would have to include C-language | routines that get called by the RTS at certain points: | * when the RTS starts executing Haskell code in an OS thread | (grabCapability) | * when the RTS stops executing Haskell code in an OS thread | (releaseCapability) | * when the RTS is about to spawn a new thread in response to | a callback (scheduleThread_). That might be ok provided there was a single context "in play". In effect, your proposal amounts to keeping a process-global context, and zapping it into the Current Haskell Worker Thread whenever it grabs a capability, correct? But if there's a single global context, why does it need to be thread-local? Another possibility that Simon and I have discussed is to provide a sort of forkIO that says "create a Haskell thread permanently bound to an OS thread". Much more expensive than normal forkIO. More like having a permanent secretary at your beck and call, rather than the services of a typist from the typing pool. Simon