Native Threads in the RTS
Sat, 23 Nov 2002 00:03:43 +0100
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
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.