Native Threads in the RTS

[Nicolas Oury]

Hello,
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 =
problem=20
>> 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 =
soon=20
> 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 =
only...

>> I don't know if it is planned but I think it could be great to be =
able=20
>> 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
problem.

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 =
the=20
> simple solution I proposed. After that, we can still design a more=20
> complex solution that addresses these two issues.
>
Great,

Best regards,
Nicolas Oury


> Cheers,
>
> Wolfgang Thaller
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>