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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 08E5CBC69 for ; Mon, 12 Nov 2007 21:52:20 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPxLOEdQDPJlgWdsb2JhbACPCgEBCQQEE4En X-IronPort-AV: E=Sophos;i="4.21,406,1188770400"; d="scan'208";a="4154461" Received: from smtp28.orange.fr ([80.12.242.101]) by mail2-smtp-roc.national.inria.fr with ESMTP; 12 Nov 2007 21:52:19 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2818.orange.fr (SMTP Server) with ESMTP id 8CFFC7000098 for ; Mon, 12 Nov 2007 21:52:19 +0100 (CET) Received: from localhost.localdomain (unknown [193.250.20.156]) by mwinf2818.orange.fr (SMTP Server) with ESMTP id 5AD167000088 for ; Mon, 12 Nov 2007 21:52:18 +0100 (CET) X-ME-UUID: 20071112205218372.5AD167000088@mwinf2818.orange.fr Date: Mon, 12 Nov 2007 20:54:11 +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: <20071112205411.0d2d6dfc@localhost.localdomain> In-Reply-To: <1194828182.4737a196e3582@webmail.in-berlin.de> References: <20071110230145.3aebafe4@localhost.localdomain> <20071111150720.4f8d1c44@localhost.localdomain> <1194799714.473732620f33e@webmail.in-berlin.de> <20071111204019.4697d387@localhost.localdomain> <1194828182.4737a196e3582@webmail.in-berlin.de> 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; printf:01 printf:01 stdout:01 suppressing:01 bug:01 locates:98 threads:01 imho:01 imho:01 oliver:01 caml-list:01 btw:03 flush:03 let:03 let:03 > > > let code1 () = > > > let x = ref 0 in > > > while true do > > > incr x; > > > Printf.printf "alpha %d\n" !x; > > > flush stdout > > (* ; > > display_mode false; > > fill_circle 100 100 20; > > synchronize ()*) > > > done > [...] > > Why do you want to call synchronize that often? > > I didn't tested your code, so I don't know what's going wrong. > But calling synchronize that often IMHO makes no sense. > It's similar to calling Thread.yield to often. > > For an average eye/viewer, it would be enough to call > synchronize all 1/25 seconds. > So, a thread that makes the timing and then calls > synchronize would be the right way, IMHO. > Or if you need higher frame rates, call it more often. > But I doubt in today machines, putting it inside a loop as you did, > would make sense. > And it also will waste ressources. It's not needed that fast, > because the eye is not fast enough. > So, there is no reason to call that function so often. Hi Oliver ! I agree doing this call to 'synchronize' at this rate has absolutely no meaning. The reason it appears here : because I removed the statements of my hanging code one by one until it remains enough to stick 'wait_next_event'. > BTW: What's about your code, you sent? > Did you throw it away, or do you want some help there? > It looked to big for spare time, but maybe the next days > I can look on it. The first link was to another dummy code only intended to demonstrate the encountered issue with 'wait_next_event' + threads. In fact the true application where the problem originally raised is : http://fabrice.marchant.free.fr/funLife/ Y. A. Game of Life. ..* (*** is a good test pattern.) .*. The thread code locates in ten lines autoplay.ml. Suppressing the loop delay will cause 'wait_next_event' (and me) to be stuck : the aim was to run the game at full speed. I didn't found anything about a bug in 'wait_next_event' so I ask : who could say what's wrong in a thread loop without this f*ckin delay ? Regards, Fabrice