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

[Oliver Bandel <oliver@first.in-berlin.de>]

Hi,


Zitat von Fabrice Marchant <fabrice.marchant@orange.fr>:

> > Both threads use the Graphics-module (via View-module).
> > Possibly the problem is, that the access
> > is not protected: use Mutexes, when calling the View.<function>,
> > so that each Thread only has access to the View-functions
> > (and the Graphics module's functions), when the other thread
> > is ready with it's work. Otherwise possibly things become confused.
> >
> > So, wrap each of the View.<function> calls with
> > calls to Mutex.lock and Mutex.unlock.
> >
> > Possibly this is your main problem!
>
>   Great ! Oliver, it was this. All perfectly rocks at full speed now.

Heheh, fine.
So, it was not OCaml nor the Graphics module that is buggy ;-)


> I'm very happy my Game of Life finally works.

Are the new sources online?
How to play it?
Now that it works, I may play around with it for a while.... :)




> 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.)

One could write a wrapper-lib for it, so that
the Mutex-stuff is already inside then.
But that is something that should be up to the
users of the Graphics-module (and not the OCaml-team),
because needs and design might be differing a lot.
If people for example would not want to have Threads inside,
with such a wrapper-lib they would be inside nevertheless.
And that's, how bloat-projects start to evolve. ;-)


Ciao,
   Oliver