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

[Claus Reinke]

pardon me if I chime in without knowing the implementation details,
but I'm an HOpenGL user who tends to like Haskell concurrency
(if only we had Erlang-style distribution in the main-ghc line..:).

And I do have the feeling that the suggested solutions keep getting
more complex, moving away from programming in the language into
controlling its implementation. I still like Sven's idea - noone has asked
for a new OS thread for the callbacks, so there shouldn't be one, so
there shouldn't be a problem with the admittedly not nice use of
OS-thread-local storage.

The argument against that suggestion was that --enable-threaded-rts
explicitly asks ghc to run Haskell threads in >= 2 OS threads, to
reduce problems with blocking external calls. That alone still isn't a
problem, but the default to run callbacks in a different OS-thread is
(so the RTS doesn't seem to manage OS-threads as resources, but
allocates them according to a pre-defined scheme that works in
many sane situations). Incidentally, while GLUT callbacks are made,
the original Haskell thread should be calling out to the GLUT mainloop,
which doesn't return, also suggesting that one should reuse that OS thread.

Others have suggested a 1-1 correspondence between OS and Haskell
threads, but I don't believe that would be a good idea with current OSs.

But if you mix all this together, you get another option:
- introduce Haskell thread groups (HTG)
- a HTG is a collection of Haskell threads that share one OS thread
  (alternatively, each HTG could have two OS-threads - one for *all*
   outgoing and incoming external calls, one for internal processing)
- add a forkGroup, which starts a new Haskell thread in its own HTG
  (using different OS-threads is the only difference between Haskell
   threads in different HTGs)

Now, there is no need for the --enable-threaded-rts option: if the Haskell
programmer expects problems with blocking external calls, she can simply
run several HTGs. There is no problem with OpenGLs peculiarities, as long
as callbacks really call back, into the same HTG, that is. This probably needs
some additional bookkeeping, to make callbacks HTG/OS-thread-specific.
And, best of all, there are fewer low-level controls out of reach of the Haskell
program.

Of course, there must be disadvantages as well..

Claus