Native Threads in the RTS
Tue, 19 Nov 2002 01:28:16 +0100
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.