From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 48DAFBC69 for ; Sun, 11 Nov 2007 22:11:30 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAO7+NkdQDPIalmdsb2JhbACPBAEBAQEHBAYHChEHgQ8 X-IronPort-AV: E=Sophos;i="4.21,402,1188770400"; d="scan'208";a="5679470" Received: from smtp20.orange.fr ([80.12.242.26]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Nov 2007 22:11:30 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2006.orange.fr (SMTP Server) with ESMTP id 7F6281C00098 for ; Sun, 11 Nov 2007 22:11:29 +0100 (CET) Received: from localhost.localdomain (unknown [193.250.28.217]) by mwinf2006.orange.fr (SMTP Server) with ESMTP id 274131C0008B for ; Sun, 11 Nov 2007 22:11:27 +0100 (CET) X-ME-UUID: 20071111211128160.274131C0008B@mwinf2006.orange.fr Date: Sun, 11 Nov 2007 21:13:18 +0100 From: Fabrice Marchant To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ? Message-ID: <20071111211318.375f2ed7@localhost.localdomain> In-Reply-To: <20071111183530.GA19575@localhost> References: <20071110230145.3aebafe4@localhost.localdomain> <20071111150720.4f8d1c44@localhost.localdomain> <1194799714.473732620f33e@webmail.in-berlin.de> <20071111183530.GA19575@localhost> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.13; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; 0100,:01 bandel:01 snippets:01 scheduler:01 printf:01 printf:01 camlprim:01 val:01 stdout:01 berke:01 durak:01 0.01:98 wrote:01 wrote:01 oliver:01 Hi, Thanks for the help ! On Sun, 11 Nov 2007 19:35:30 +0100 Julien Moutinho 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