Native Threads in the RTS

[Wolfgang Thaller]

Nicolas Oury wrote:

> I don't know if what I say is pertinent, but there was another problem 
> 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 ran in the same thread as the Opengl/GLUT things...

Good point. That feature won't be covered by my first proposal (As I 
said, I'll write up a proper document about that ASAP, that is, as soon 
as I find an entire hour of free time). It sounds useful at first, but 
I'm not that sure about it: after all, we can't rely on when the 
finalizer will be executed: the thread might no longer be around, and 
the GLUT window might be long closed. We should definitely think about 
it a little more, though.

> I don't know if it is planned but I think it could be great to be able 
> 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 executed in the new OS thread. These new threads  would be  
> blocked on other threads in that kernel thread blocked, but can all 
> access to this library, and will make programming easier.

This sounds a lot like the "thread group" idea that somebody had when 
we last discussed this. I think it gives us added flexibility at the 
cost of more difficult implementation and the danger of accidentally 
blocking OS threads [it might be just yet another source of bugs].

I'll first write up something in order to explain/accurately define the 
simple solution I proposed. After that, we can still design a more 
complex solution that addresses these two issues.

Cheers,

Wolfgang Thaller