Native Threads in the RTS
Tue, 19 Nov 2002 00:04:03 +0100
I don't know if it is planned but I think it could be great to be able=20=
to have, in the new OS thread for OpenGL, an "expressivity only"
concurrence system. I mean that to be able to fork user threads that are=20=
executed in the new OS thread. These new threads would be blocked on=20=
other threads in that kernel thread blocked, but can all access to this=20=
library, and will make programming easier.
Le vendredi 15 novembre 2002, =E0 06:02 , Wolfgang Thaller a =E9crit :
> Hello All,
> A while ago there was a discussion on the shortcomings of the threaded=20=
> RTS (in short, it doesn't work with foreign APIs that use thread-local=20=
> state, and that breaks HOpenGL). Back then, it was decided to just =
> the threaded RTS off by default and to do something about it some time=20=
> after 5.04.
> I believe it's time to think about it again, so I'll take the liberty=20=
> 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=20=
> in. Note that the fact that only one Haskell thread may execute at a=20=
> time remains unchanged.
> Whenever the scheduler determines that a "native" haskell thread is=20
> next, it sends the OS worker thread to sleep and wakes up the OS =
> corresponding to the "native" haskell thread. When the "native" =
> thread yields again, so does the corresponding OS thread.
> Foreign calls from "normal" (non-native) haskell threads should be=20
> handled in exactly the same way as they are currently.
> If a callback is entered and the current OS thread corresponds to a=20
> native haskell thread, the callback should be executed in the current=20=
> OS thread.
> Other haskell threads continue to run in the worker thread or in their=20=
> own dedicated OS thread.
> Programs that don't use forkNativeThread won't be affected by the=20
> change. Thread switching to and from native threads will be slower, =
> not painfully slow.
> Wrapping an entire HOpenGL program in forkNativeThread should solve =
> OpenGL/GLUT thread-local-state problem, for example, and who knows =
> else it is good for.
> Any comments? Opinions?
> Glasgow-haskell-users mailing list