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=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id BE901BC69 for ; Mon, 12 Nov 2007 22:18:35 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI9SOEfAbSoIh2dsb2JhbACPCQEBAQgKKQ X-IronPort-AV: E=Sophos;i="4.21,407,1188770400"; d="scan'208";a="19202790" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP; 12 Nov 2007 22:18:35 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id lACLIY3X022018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Nov 2007 22:18:34 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id lACLIYF9022015 for caml-list@yquem.inria.fr; Mon, 12 Nov 2007 22:18:34 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-108-186.pools.arcor-ip.net (dslb-088-073-108-186.pools.arcor-ip.net [88.73.108.186]) by webmail.in-berlin.de (IMP) with HTTP for ; Mon, 12 Nov 2007 22:18:34 +0100 Message-ID: <1194902314.4738c32a070fd@webmail.in-berlin.de> Date: Mon, 12 Nov 2007 22:18:34 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply anymore ? 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> <20071112205411.0d2d6dfc@localhost.localdomain> In-Reply-To: <20071112205411.0d2d6dfc@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 browsed:01 mutexes:01 module's:01 toplevel:01 threads:01 threads:01 oliver:01 oliver:01 caml-list:01 functions:01 defined:02 graphics:02 mutex:03 Hi Fabrice, Zitat von Fabrice Marchant : [...] > In fact the true application where the problem originally raised is : > http://fabrice.marchant.free.fr/funLife/ [...] I only have looked some minutes into the code. fast browsed ;-) Both threads use the Graphics-module (via View-module). Possibly the problem is, that the access is not protected: use Mutexes, when calling the View., so that each Thread only has access to the View-functions (and the Graphics module's functions), when the other thread is ready with it's work. Otherwise possibly things become confused. So, wrap each of the View. calls with calls to Mutex.lock and Mutex.unlock. Possibly this is your main problem! Ciao, Oliver P.S.: The Mutex must be in the environment of both threads, so must be defined at the toplevel of the autoPlay.ml, which means unit-global, as "running" also is.