Native Threads in the RTS

Nicolas Oury
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...

Best regards,
Nicolas Oury

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?
> Wolfgang
> _______________________________________________
> Glasgow-haskell-users mailing list