Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
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)
{
    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.