Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?

[Fabrice Marchant <fabrice.marchant@orange.fr>]

On Tue, 13 Nov 2007 11:14:32 +0100
Oliver Bandel <oliver@first.in-berlin.de> wrote:

> So, it was not OCaml nor the Graphics module that is buggy ;-)
  But I wonder why I didn't see any word about these necessary
"precaution" in doc. (Maybe have missed something ?)

> > I'm very happy my Game of Life finally works.
> 
> Are the new sources online?
The code is'nt yet very clean but I seize the opportunity to show
it you offer to me :
http://fabrice.marchant.free.fr/fl/funLife/
> How to play it?
Press '?' or 'H' for help page ( directed to console ).

> Now that it works, I may play around with it for a while.... :)
  It features an "infinite" board, a zoom, mouse dragging of the
view, history and customizable colours. Many things can be changed
"on the fly" - when automaton is running - but maybe it remains
some bugs about this.
  ( Nothing to do with the powerful top speed "xlife". )
However, 'll try to improve and the TODO list is long...

> > However, I've not understood why this Mutex was needed : what could be
> > the data shared with 'wait_next_event' ?
> >   Some internal of Graphics module ?
> 
> Yes, Graphics modules internals.
> Both threads might share a lot of data.
> They are drawing at the same screen,
> so if their work might be interrupted by the
> scheduler before the data was written completely,
> something might go wrong.
> 
> If you can't be sure that the data is isolated,
> use Mutexes. And in the case of the Graphics-module you
> don't get back a value that holds something,
> e.g. when using the initialization functions.
> So seemingly they all write on the same data.
> (And to have a copy of the whole screen always,
>  would be wasting memory, so I think it's ok this way.)
  I tried to use Mutex again this way for changing autoplay speed.
Seems to work.

Regards,

  Fabrice