Native Threads in the RTS

[Wolfgang Thaller]

Hello All,

A while ago there was a discussion on the shortcomings of the threaded 
RTS (in short, it doesn't work with foreign APIs that use thread-local 
state, and that breaks HOpenGL). Back then, it was decided to just keep 
the threaded RTS off by default and to do something about it some time 
after 5.04.
I believe it's time to think about it again, so I'll take the liberty 
of proposing an extension to the RTS that might solve the problem.

I propose adding something like

forkNativeThread :: IO () -> IO ()

which forks a new Haskell thread that has its own OS thread to execute 
in. Note that the fact that only one Haskell thread may execute at a 
time remains unchanged.
Whenever the scheduler determines that a "native" haskell thread is 
next, it sends the OS worker thread to sleep and wakes up the OS thread 
corresponding to the "native" haskell thread. When the "native" haskell 
thread yields again, so does the corresponding OS thread.

Foreign calls from "normal" (non-native) haskell threads should be 
handled in exactly the same way as they are currently.

If a callback is entered and the current OS thread corresponds to a 
native haskell thread, the callback should be executed in the current 
OS thread.
Other haskell threads continue to run in the worker thread or in their 
own dedicated OS thread.

Programs that don't use forkNativeThread won't be affected by the 
change. Thread switching to and from native threads will be slower, but 
not painfully slow.

Wrapping an entire HOpenGL program in forkNativeThread should solve the 
OpenGL/GLUT thread-local-state problem, for example, and who knows what 
else it is good for.

Any comments? Opinions?


Wolfgang