From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <julien.moutinho@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,SPF_NEUTRAL 
	autolearn=disabled version=3.1.3
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 B2243BC69
	for <caml-list@yquem.inria.fr>; Sun, 11 Nov 2007 19:34:48 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAADbaNkdC+Vytlmdsb2JhbACPBAEBAQEHBAYHChEHgQ8
X-IronPort-AV: E=Sophos;i="4.21,402,1188770400"; 
   d="scan'208";a="19165694"
Received: from ug-out-1314.google.com ([66.249.92.173])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Nov 2007 19:34:48 +0100
Received: by ug-out-1314.google.com with SMTP id m3so617576ugc
        for <caml-list@yquem.inria.fr>; Sun, 11 Nov 2007 10:34:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:received:date:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from;
        bh=84vOK6o8FPr2eO0ObQE8AdXAeiOuqWnrBD5Qm4q44IM=;
        b=VWIEngivhH2tFVV23lj87bRxvXeY7mFXkDjYPvEJ0J44lVjyy2fuMopMRovP9w/GXLEjanQpCmGzwPxWa/usDYKQugi8hW1G1MdXvjLRrAbolT8j2rbcaoV2/6KTOiXLr4aFbXCkOx8kdwy+ONlmZpmGf2KHkQD5Rx4JIYBGzXk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:date:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from;
        b=UwqHTIE/1M8d5kmXpGBlShsSwGlligffNGZ+EOhQaHpn8ceD/lDWz1SE+/47aa9yPf5g0fcvI3AFCbb5Hxzdmv9rgbgDSDNpIJQtmVqfO6WXINEyhlOev810kg+Tu4bxXvAfPeeat8K5Exi0am/MZ/fq27cj9ZQjWjU+z6BgT7U=
Received: by 10.67.195.14 with SMTP id x14mr534318ugp.1194806087408;
        Sun, 11 Nov 2007 10:34:47 -0800 (PST)
Received: from localhost ( [82.122.118.149])
        by mx.google.com with ESMTPS id m5sm2099533gve.2007.11.11.10.34.43
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sun, 11 Nov 2007 10:34:46 -0800 (PST)
Received: by localhost (sSMTP sendmail emulation); Sun, 11 Nov 2007 19:35:30 +0100
Date: Sun, 11 Nov 2007 19:35:30 +0100
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Why 'Graphics.wait_next_event' doesn't reply
	anymore ?
Message-ID: <20071111183530.GA19575@localhost>
References: <20071110230145.3aebafe4@localhost.localdomain> <20071111150720.4f8d1c44@localhost.localdomain> <1194799714.473732620f33e@webmail.in-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1194799714.473732620f33e@webmail.in-berlin.de>
User-Agent: Mutt/1.5.17 (2007-11-01)
From: Julien Moutinho <julien.moutinho@gmail.com>
X-Spam: no; 0.00; 0100,:01 bandel:01 scheduler:01 scheduler:01 printf:01 printf:01 camlprim:01 val:01 stdout:01 wrote:01 oliver:01 caml-list:01 hangs:01 seems:03 seems:03 

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.