English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Why 'Graphics.wait_next_event' doesn't reply anymore ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-11-13 (21:08)
From: Fabrice Marchant <fabrice.marchant@o...>
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
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 :
> 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.