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

_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users