[HOpenGL] HOpenGL and --enable-threaded-rts

[Simon Peyton-Jones]

| > 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.
|=20
| 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
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