[HOpenGL] HOpenGL and --enable-threaded-rts
Thu, 20 Jun 2002 09:06:53 +0100
| > Another possibility that Simon and I have discussed is to provide a=20
| > sort of forkIO that says "create a Haskell thread=20
| permanently bound to=20
| > an OS thread". Much more expensive than normal forkIO. More like=20
| > having a permanent secretary at your beck and call, rather than the=20
| > services of a typist from the typing pool.
| So calling C from this thread would happen inside that OS thread,=20
| callbacks would happen in that OS thread, and the RTS would=20
| continue to=20
| run while that OS thread is blocked?
| How much overhead would that create? I wouldn't like much additional=20
| overhead for my OpenGL programs :-(. Would this require an OS=20
| mutex lock=20
| for every heap allocation, or is there a better way?
The idea would be that we'd keep the invariant that only one OS=20
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
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
OS thread runs the super-thread. When its time slice is up, the
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
Havn't worked out the details, but it looks possible.
Sigbjorn: any comments? You'd implemented all this thread-y stuff.