Hello, Le mardi 19 novembre 2002, à 01:28 , Wolfgang Thaller a écrit :
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.
These problems always appears with finalizer. An example (maybe a bit strange but) : one can want to close a window when the program can't reach it anymore. It may sound more realistic if it is closing an 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 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].
It is not bad that threads working in the OpenGL world are blocked when OpenGL can't receive orders. The user would see new OS thread as a thread for a kind of group : group of people using OpenGL, are blocked wwhen OpenGl blocks. Think again of other example : imagine the glorious haskell web server using a database library allowing only one thread access. One can't write all the request in only one thread, the programmer will have to add a monothreaded layer that serve requests from other threads that are preparing pages with database datas. I don't know if that library (database monothread) exits but a good exercise would be to all try to find example library relevant to this problem. I can start adding a small example : SDL, which allows to manage every low level parts of 2D games and all 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 same thread for pumping events (asking what have be done), than the one which was use to open video window !!! A program would here be far better organize if multithreaded is allowed in one thread... With that kind of problem, having a way to program multithreaded and run monothread is a power. As there already is user level threads, it would be a pity to lose that.
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.
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