Native Threads in the RTS

Nicolas Oury
Fri, 22 Nov 2002 18:22:49 +0100

I read your proposal. It's great but I have a few remarks :

* I think that, if it is not too much complicated, it could be great to 
put many threads in the OpenGL OS thread. The goal of concurrent Haskell 
was to allow concurrency for expressivity. It would be a pity to lose 
this in part of programs for technical reason. Having this possibility 
would also be a pro this language : Haskell would be the only language 
to have safe multithreaded OpenGL programming.

*Another problem can raise : if one render in two different OpenGL 
windows, he may want to use different threads for these rendering. 
However, this is impossible for the moment because it would implies that 
user threads know when a switch has occurred to a thread rendering in 
another context and swap OpenGL context.  This implies a notion of 
either : allowing to execute arbitrary code on switch ; either 
introducing a notion of "family" of threads. When a switch occurs to a 
member of a family different of the last member of the family executed , 
some user defined code should be  executed (in that case the code 
perform a context switch). family and members of family would be defined 
by user.  It seems that family and OS threads are independent : it could 
either be multiple OS threads for a family or multiple families for an 
OS threads. I think a thread could be member of multiple families (even 
if I can't see pertinent example so far). I also think that multiple 
threads can be the same member of a family (multiple threads drawing in 
the same window).

* A simple way of introducing these new notions (family, members,  OS 
threads) would be to define them as first class value.
   This would ease the problem of callback : an OpenGL callback would 
simply be a call to an operator telling the OpenGL thread to execute 
really the callback. "threadsafe" could be a short hand for wrapping a 
callback in a call to the thread currently executing (at time of the 
call to threadsafe function) and give it to extern function.

* To protect OpenGL operations, it would perhaps be useful to introduce 
a mechanism forbidding to switch between members of a family between a 
critical section. (I don't know what do a context switch between a 
glBegin and glEnd).

I don't know if my proposal is pertinent but it addresses some problems 
that would arise. It's quite complicated but i think that there is no 
overcost for people who don't need using it.

Best regards,
Nicolas Oury