Native Threads in the RTS
Mon, 18 Nov 2002 23:39:08 +0100
I don't know if what I say is pertinent, but there was another problem=20=
that was discussed in the thread about threaded RTS.
One may want to use a finalizer in a particular thread.
For example, a finalizer that put make a rotating cube on screen must be=20=
ran in the same thread as the Opengl/GLUT things...
Le vendredi 15 novembre 2002, =E0 06:02 , Wolfgang Thaller a =E9crit :
> 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