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

Simon Marlow simonmar@microsoft.com
Tue, 18 Jun 2002 12:33:57 +0100

> Has anyone already thought about how to solve this problem?
> I'm thinking about adding hooks to the RTS (in grabCapability,=20
> releaseCapability and scheduleThread_) which would be used=20
> for setting=20
> up the correct thread-local state whenever Haskell execution=20
> "switches"=20
> to a different OS thread. Those hook routines would have to=20
> be written=20
> in C and would be platform-specific most of the time. It's not a nice=20
> solution, but it's the only one I can think of at this time.
> Unless someone comes up with a better idea _quickly_, I'll try it out=20
> and then report how ugly it really is... :-)

I can't see a nice solution to this problem - it really invalidates one
of the key assumptions in the threaded implementation of the RTS, namely
that it doesn't matter which OS thread we use to execute Haskell code.

I suspect that a "safe" foreign import could be made to switch threads
to the right OS thread before entering C land, but that's way too much
overhead to impose on every single FFI call from Haskell.

Yes, my guess is that this will probably have to be done by manipulating
the thread-local state in the RTS - grab the current thread-local state
whenever a call is made into Haskell, and whenever we run a Haskell
thread we have to set the appropriate thread-local state.  Perhaps it
should be stored in the TSO and inherited by child threads too.

The trouble is that there isn't a single object representing the whole
thread-local state.  Does OpenGL use pthread_getspecific() and
pthread_setspecific() to access its thread-local state?