Native Threads in the RTS

[Nicolas Oury]

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 =
thread=20
> corresponding to the "native" haskell thread. When the "native" =
haskell=20
> 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, =
but=20
> not painfully slow.
>
> Wrapping an entire HOpenGL program in forkNativeThread should solve =
the=20
> OpenGL/GLUT thread-local-state problem, for example, and who knows =
what=20
> else it is good for.
>
> Any comments? Opinions?
>
>
> Wolfgang
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>