Native Threads in the RTS

[Wolfgang Thaller]

Nicolas Oury a =E9crit:

> * I think that, if it is not too much complicated, it could be great=20=

> to put many threads in the OpenGL OS thread. The goal of concurrent=20
> Haskell was to allow concurrency for expressivity. It would be a pity=20=

> to lose this in part of programs for technical reason. Having this=20
> possibility would also be a pro this language : Haskell would be the=20=

> only language to have safe multithreaded OpenGL programming.

You can safely render into two different OpenGL contexts from two=20
different OS threads. I don't think that rendering into the same=20
context from two green threads would work - the OpenGL interface is far=20=

too thread-based for this to be useful.

> *Another problem can raise : if one render in two different OpenGL=20
> windows, he may want to use different threads for these rendering.=20
> However, this is impossible for the moment because it would implies=20
> that user threads know when a switch has occurred to a thread=20
> rendering in another context and swap OpenGL context.  This implies a=20=

> notion of either : allowing to execute arbitrary code on switch ; >=20
> [...]

If we want to render into two different OpenGL windows in parallel, we=20=

can use two OS threads. OpenGL keeps a reference to its current OpenGL=20=

context on a per-OS-thread basis (some old OpenGL implementations might=20=

not support this, but I think we can ignore them).

> [...] some user defined code should be  executed (in that case the=20
> code perform a context switch) [...]

Haskell Code won't work here [after all, we're between two haskell=20
threads...]. C code would be no problem. I actually proposed something=20=

like this as a stopgap measure for making OpenGL work with the threaded=20=

RTS in summer, but I was convinced by others on this list that this is=20=

a "hackish" solution that relies on internals of the RTS far too much.

> It seems that family and OS threads are independent : it could either=20=

> be multiple OS threads for a family or multiple families for an OS=20
> threads. I think a thread could be member of multiple families (even=20=

> if I can't see pertinent example so far). I also think that multiple=20=

> threads can be the same member of a family (multiple threads drawing=20=

> in the same window).

What would it mean if a thread was a member of more than one thread=20
families? Would it mean that it might execute in several different OS=20
threads? Also, how would these thread groups interact with the existing=20=

threaded RTS? Would the existing features still be available without=20
additional effort? Would they be implemented on top of these thread=20
families?

I'm not quite convinced that the thread families approach would be=20
worth the additional complexity. What would it be used for?

> * To protect OpenGL operations, it would perhaps be useful to=20
> introduce a mechanism forbidding to switch between members of a family=20=

> between a critical section. (I don't know what do a context switch=20
> between a glBegin and glEnd).

We already have MVars, they can be used for things like that.

Can anybody else think of reasons why we should need a more complicated=20=

design where threads are put into different "families" or "groups",=20
where each thread group executes in exactly one OS thread?
This has been proposed at least twice now, but I fail to see the=20
advantages (it looks more flexible, but what's it _for_?).
Some disadvantages of a thread groups approach are:
*) More complexity.
*) Foreign calls will block other threads in the same group.
*) It would be even less meaningful for a haskell implementation that=20
always uses OS threads --- the native/green threads proposal could be=20
implemented as a no-op (forkNativeThread =3D forkIO) without breaking=20
programs that use it.
Somebody else please fill in the advantages.

Cheers,
Wolfgang