Native Threads in the RTS
Fri, 15 Nov 2002 18:02:07 +0100
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
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
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?