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, <victor-caml-list@nicollet.net> 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
>