Native Threads in the RTS
Tue, 19 Nov 2002 09:16:07 +0100
Le mardi 19 novembre 2002, =E0 01:28 , Wolfgang Thaller a =E9crit :
> Nicolas Oury wrote:
>> I don't know if what I say is pertinent, but there was another =
>> 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=20=
>> 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=20=
> said, I'll write up a proper document about that ASAP, that is, as =
> as I find an entire hour of free time). It sounds useful at first, but=20=
> I'm not that sure about it: after all, we can't rely on when the=20
> finalizer will be executed: the thread might no longer be around, and=20=
> the GLUT window might be long closed. We should definitely think about=20=
> it a little more, though.
These problems always appears with finalizer. An example (maybe a bit=20
strange but) : one can want to close a window when the program can't=20
reach it anymore. It may sound more realistic if it is closing an=20
unreachable database with a databasse library made for one thread =
>> I don't know if it is planned but I think it could be great to be =
>> 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=20=
>> are executed in the new OS thread. These new threads would be =20
>> blocked on other threads in that kernel thread blocked, but can all=20=
>> access to this library, and will make programming easier.
> This sounds a lot like the "thread group" idea that somebody had when=20=
> we last discussed this. I think it gives us added flexibility at the=20=
> cost of more difficult implementation and the danger of accidentally=20=
> blocking OS threads [it might be just yet another source of bugs].
It is not bad that threads working in the OpenGL world are blocked when=20=
OpenGL can't receive orders.
The user would see new OS thread as a thread for a kind of group : group=20=
of people using OpenGL, are blocked wwhen OpenGl blocks. Think again of=20=
other example : imagine the glorious haskell web server using a=20
database library allowing only one thread access. One can't write all=20
the request in only one thread, the programmer will have to add a=20
monothreaded layer that serve requests from other threads that are=20
preparing pages with database datas.
I don't know if that library (database monothread) exits but a good=20
exercise would be to all try to find example library relevant to this=20
I can start adding a small example :
SDL, which allows to manage every low level parts of 2D games and all=20
that isn't OpenGl in an OpenGl game.
I have a small and dirty binder to SDL, and in SDL one have to use the=20=
same thread for pumping events (asking what have be done), than the one=20=
which was use to open video window !!!
A program would here be far better organize if multithreaded is allowed=20=
in one thread...
With that kind of problem, having a way to program multithreaded and run=20=
monothread is a power. As there already is user level threads, it would=20=
be a pity to lose that.
> I'll first write up something in order to explain/accurately define =
> simple solution I proposed. After that, we can still design a more=20
> complex solution that addresses these two issues.
> Wolfgang Thaller
> Glasgow-haskell-users mailing list