| > 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. | | So calling C from this thread would happen inside that OS thread, | callbacks would happen in that OS thread, and the RTS would | continue to | run while that OS thread is blocked? | How much overhead would that create? I wouldn't like much additional | overhead for my OpenGL programs :-(. Would this require an OS | mutex lock | for every heap allocation, or is there a better way? The idea would be that we'd keep the invariant that only one OS thread can be executing Haskell at any moment. So no mutex locks on allocation or thunk entry. Suppose we call one of a Haskell-thread-with-a-dedicated-OS-thread a "Haskell super-thread". At any moment, a vanilla OS worker thread is executing Haskell threads. It keeps picking a new Haskell thread, running it for a while, then picking a new one. OK, so it decides that the next Haskell thread to run is a super-thread. The OS thread hands off control to the dedicated OS thread bound to the super-thread. The dedicated OS thread runs the super-thread. When its time slice is up, the dedicated OS thread picks a new Haskell thread to run, but it doesn't run it! No, it hands off control to a vanilla OS worker thread instead. The intention is zero overhead if there are no super threads. There'll be an OS thread switch whenever the super-thread is scheduled, but that's life. Havn't worked out the details, but it looks possible. Sigbjorn: any comments? You'd implemented all this thread-y stuff. Simon