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-11 (18:34)
From: Julien Moutinho <julien.moutinho@g...>
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ?
On Sun, Nov 11, 2007 at 05:48:34PM +0100, Oliver Bandel wrote:
> [...]
> This code looks ugly.
I've just noticed the id := Some (Thread.create run ())
coupled with the [while !id <> None do] in run:
it seems possible that the while loop never starts.
And the useless call to Thread.exit.
But I think these are unrelated stuffs to the real matter:
the thread running wait_next_event seems to never get
the attention of the thread scheduler.

> Why?
> [...]
> It forces calls to the scheduler all too often.
> And it does it at three places. And in the print-loop
> it clals it every time!
Are you sure?

> This is the way of wasting ressources.
> Here is the code (I have tested it, and it works):
Unfortunately, if I remove the calls to Printf/flush in code1,
then the thread running wait_next_event still hangs up,
I mean has no time to run as in Fabrice's code (without the call
to Thread.delay).

I tried to replace Printf/flush calls by a simple call to:
CAMLprim value
release_master_lock (value unit)
    return Val_unit;
and I observed that the thread running wait_next_event
does not hang up, as with the Printf/flush calls.

Hence, I think it's only because Printf/flush release the master
lock when they try to lock the mutex of stdout, that your proposal
works better.

Fabrice: I would expect Thread.yield to help in such situation,
but I am unable to get something out of it.

Just my humble remarks,