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

[Simon Peyton-Jones]

| My proposal is to leave dealing with thread-local state to=20
| the library=20
| binding (in this case, HOpenGL). This requires just a little support=20
| from the RTS. The library binding would have to include C-language=20
| routines that get called by the RTS at certain points:
| * when the RTS starts executing Haskell code in an OS thread=20
| (grabCapability)
| * when the RTS stops executing Haskell code in an OS thread=20
| (releaseCapability)
| * when the RTS is about to spawn a new thread in response to=20
| 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? =20

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=20
services of a typist from the typing pool.

Simon