HOpenGL and --enable-threaded-rts

[Simon Peyton-Jones]

This is nasty.  As I understand it,=20

* GLUT assumes that the same OS thread executes some Haskell code,
calls C, which calls back to Haskell.

* Concurrent Haskell never lets this happen, for very good reason.=20
The thread executing Haskell code is just an anonymous OS thread
executing multiple Haskell threads. =20

The good reason is this: if one designated OS thread must execute
a particular bunch of Haskell code, what if that OS thread gets blocked
doing I/O on behalf of some other Haskell thread?  It's hard to say
just which Haskell threads "belong" to that designated OS thread.

The only thing I can think of is that the Haskell call-back thread
somehow says that it can only be executed by the designated
OS thread; and when blocks (the Haskell call-back, that is) the
OS thread doesn't grab another Haskell thread to execute, but
instead steps aside for an anonymous worker thread to do the job.
Makes it all more complicated, alas.

Is there no way to get the "current context" explicitly, and treat
it as some kind of "handle" that accompanies GLUT calls?

I counsel caution here.  It's easy to hack something up that
will puzzle us for generations.  Check out Sigbjorn's notes in the
GHC commentary.  Whatever we end up doing should be documented
there.

Simon

| -----Original Message-----
| From: Wolfgang Thaller [mailto:wolfgang.thaller@gmx.net]=20
| Sent: 16 June 2002 20:57
| To: hopengl@haskell.org
| Cc: GHC List
| Subject: HOpenGL and --enable-threaded-rts
|=20
|=20
| In short, it doesn't work :-( .
| OpenGL (at least on MacOS) keeps track of the "current context" on a=20
| per-thread basis. The GLUT library sets the current context and calls=20
| back to the program. With GHC 5.03 compiled with=20
| --enable-threaded-rts,=20
| the callback gets executed in a different thread. There is no OpenGL=20
| context set up for that thread, so the first OpenGL call=20
| crashes. This might also be a problem for other state-based=20
| interfaces that use=20
| thread-local state.
|=20
| 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.=20
| Unless someone comes up with a better idea _quickly_, I'll try it out=20
| and then report how ugly it really is... :-)
|=20
| Cheers,
|=20
| Wolfgang
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
|=20