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

[Fabrice Marchant <fabrice.marchant@orange.fr>]

  Hi,

 Thanks for the help !

On Sun, 11 Nov 2007 19:35:30 +0100
Julien Moutinho <julien.moutinho@gmail.com> wrote:

> 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.
   Oliver didn't spoke about my code...
Anyway these are not real codes but rather snippets intended to track the issues.

  However what you say is right. I mentionned it in original post :
>>> There is no delay problem in changing thread 'id' after creation and process test '!id <> None' is soon true at first call.

> And the useless call to Thread.exit.
  Indeed, I removed it in original post :
>>> let run () =
>>>   while !id <> None do
>>>     step ();  (* Changes drawing state *)
>>>     plot () (* ;
>>>     Thread.delay 0.01 *)
>>>   done
>>> 
>>> let rec test () =
Should have updated blockIssue.ml source...
Thread.exit () (* <- Is it really useful, at end of thread code here ? *)

> 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.
  I agree.

> > 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 thought it was a time question too. But I performed some trials and
now doubt of this.
> 
> 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.
  I tried to put some 'yields' at different locations of the code,
just like Berke Durak did. Unfortunately they didn't change the
program behaviour.

I'm grateful for the interesting results of the trials you exposed
here.

Regards,

Fabrice