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

[Julien Moutinho <julien.moutinho@gmail.com>]

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)
{
    enter_blocking_section();
    leave_blocking_section();
    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,
  Julien.