Native Threads in the RTS

[Nicolas Oury]

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.

Best regards,
Nicolas Oury
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 =
keep=20
> 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 =
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
>