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

[Dean Herington]

Let me ask a naive question concerning the implementation of threading in
the GHC RTS.  Would it be feasible to support an alternative strategy for
mapping Haskell threads onto OS threads, namely that the two sets are kept
in one-to-one correspondence?  The thread multiplexing and migration that
GHC now supports sounds very cool, but it seems to violate assumptions of
potentially many threaded libraries.  If the 1-1 model is as
straightforward as it seems it should be, it might not be too complicated
to support both.  The 1-1 model could be selected for the entire process,
or preferably for each thread on its creation, if this is feasible.

An aside about performance: It seems the reason for thread multiplexing and
migration is performance, to allow Haskell threads to be lighter weight
than their OS counterparts.  While I agree with this point, there have
been, perhaps are, and most probably will be threading systems where OS
threads are light enough in weight to support the 1-1 model with good
performance.  So I don't think that concern over performance is by itself
enough to invalidate the usefulness of the 1-1 model.

Dean


Simon Marlow wrote:

> There are two problems with this approach, I think.  The situation is
> like this (correct me if I'm wrong):
>
>     - Haskell thread H1 running on OS thread O1 registers a
>       callback C.
>
>     - Haskell thread H1/O1 makes a blocking call into HOpenGL.
>         This call is made also in O1.  The RTS allocates another
>       OS worker thread O2, and continues running Haskell threads.
>
>     - HOpenGL, running in O1, invokes the callback C.  The RTS
>       stops O1, creates a new Haskell thread H2 in which to run C,
>         and eventually runs H2 in O2.
>
> Problem #1 is the call-in: our current implementation *always* runs the
> callback in a different OS thread from the calling thread.  It was
> simpler this way, but perhaps this can change.
>
> Problem #2 is that we would have to add some extra machinery to
> guarantee that a given Haskell thread executes in a particular OS
> thread, and somehow do it in a way that was "fair" (i.e. the Haskell
> thread with a preference for its OS thread doesn't get starved, and
> doesn't starve other threads).  The RTS currently doesn't make any
> distinction between OS threads; a given Haskell thread can even migrate
> from one OS thread to another during its execution.