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=2.0 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 A1271BB84 for ; Tue, 17 Feb 2009 21:14:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwCABypmknRVd0Vimdsb2JhbACCQTCKHYZ8PwEBAQoJEw8Frg4IgQCPYQEDAQOEEAaDbg X-IronPort-AV: E=Sophos;i="4.38,224,1233529200"; d="scan'208";a="21252641" Received: from mail-qy0-f21.google.com ([209.85.221.21]) by mail2-smtp-roc.national.inria.fr with ESMTP; 17 Feb 2009 21:14:49 +0100 Received: by qyk14 with SMTP id 14so10380647qyk.9 for ; Tue, 17 Feb 2009 12:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=8q3jty2/pfFJGT4nFGN6tfPkRuxrTeJc4zOoMMq1ZqU=; b=vKVppuyfelReY1Ja+/fMeXHiXJlzYsKVY46VSvv5+cJz4HEb6brIyX6IG0AmwLnIx+ 1PYcYtrjG5m1FATpbi4t/fEb7ETm7ha+TrI79tzELsRhtEjsU0mAS4PpMYuXW2+uF7ZD 1H+iPDjnNmMGVkdNUTTdfQNZHVLJZMXeh2Yd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=fWaQo4AhwxoFUaMCH4kWZmf7bAOVJ8UH99D84eXBpiRYIquvW5AjnVT+0ZJ+7/2iju egpLcaYH+Z+e7cvswtNdMen/QIpdy5qZBww6y/WePJb07u/DFSKYT59sPgTTc9nmaLnV MuixHtDJxi6L3kFj4BAJFDXWBm9NZNTTvGPvo= MIME-Version: 1.0 Received: by 10.229.74.68 with SMTP id t4mr1338779qcj.102.1234901688989; Tue, 17 Feb 2009 12:14:48 -0800 (PST) Reply-To: yminsky@gmail.com In-Reply-To: <20090217155455.GA2352@stock.ovh.net> References: <20090217155455.GA2352@stock.ovh.net> Date: Tue, 17 Feb 2009 15:14:48 -0500 Message-ID: <891bd3390902171214s40e4c378sc9c373f6c2822597@mail.gmail.com> Subject: Re: [Caml-list] Lazy and Threads From: Yaron Minsky To: victor-caml-list@nicollet.net Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=00163649942b8139b2046322f4ac X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 bug:01 bug:01 expr:01 expr:01 beginner's:01 ocaml:01 beginner's:01 ocaml:01 2009:98 1.0:98 2009:98 1.0:98 --00163649942b8139b2046322f4ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At a minimum, this seems like a bug in the documentation. The documentation states very clearly that Undefined is called when a value is recursively forced. Clearly, you get the same error when you force a lazy value that is in the process of being forced for the first time.... It does seem like fixing the behavior to match the current documentation would be superior to fixing the documentation to match the current behavior. I'd suggest adding a bug report to the bug tracker. y On Tue, Feb 17, 2009 at 10:54 AM, wrote: > Hello, > > I'm working with both lazy expressions and threads, and noticed that the > evaluation of lazy expressions is not thread-safe: > > let expr = lazy (Thread.delay 1.0) > > let _ = > let thread = Thread.create (fun () -> Lazy.force expr) () in > Lazy.force expr; > Thread.join thread > > The second thread to attempt an evaluation dies with Lazy.Undefined. The > source of this appears to be the standard Lazy.force behavior, which > replaces the closure in the lazy-block with a raise_undefined closure in > order to detect self-recursing lazy expressions. > > Aside from handling a mutex myself (which I don't find very elegant for > a read operation in a pure functional program) is there a solution I can > use to manipulate lazy expressions in a pure functional multi-threaded > program? > > -- > Victor Nicollet > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --00163649942b8139b2046322f4ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At a minimum, this seems like a bug in the documentation. The documentation= states very clearly that Undefined is called when a value is recursively f= orced.  Clearly, you get the same error when you force a lazy value th= at is in the process of being forced for the first time....

It does seem like fixing the behavior to match the current documentatio= n would be superior to fixing the documentation to match the current behavi= or.

I'd suggest adding a bug report to the bug tracker.

y

On Tue, Feb 17, 2009 at 10:54 AM, <victor-c= aml-list@nicollet.net> wrote:
Hello,

I'm working with both lazy expressions and threads, and noticed that th= e
evaluation of lazy expressions is not thread-safe:

 let expr =3D lazy (Thread.delay 1.0)

 let _ =3D
   let thread =3D Thread.create (fun () -> Lazy.force expr) (= ) in
     Lazy.force expr;
     Thread.join thread

The second thread to attempt an evaluation dies with Lazy.Undefined. The source of this appears to be the standard Lazy.force behavior, which
replaces the closure in the lazy-block with a raise_undefined closure in order to detect self-recursing lazy expressions.

Aside from handling a mutex myself (which I don't find very elegant for=
a read operation in a pure functional program) is there a solution I can use to manipulate lazy expressions in a pure functional multi-threaded
program?

--
Victor Nicollet

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--00163649942b8139b2046322f4ac--