Re: What are the arguments in favor of delay/force in eval.c?

[Rob Browning <rlb@defaultvalue.org>]

Kevin Ryde <user42@zip.com.au> writes:

> An even more radical idea would be not to have a mutex at all.  If
> two threads are simultaneously forcing then whichever finishes first
> sets the forced value.  (The same way that recursive forcing results
> in the first finisher setting the value.)

This would only work if you forbid side-effects, right?  Either that,
or perhaps we'd just have to document the resulting semantics,
whatever they are.

I was also wondering about the possibilities for deadlock with the
current code, and then what they might be with a srfi-45 force, which
may do more work (it's basically a trampoline approach to the problem
described in the srfi).

I suppose one of the questions here (and one of the traditional
questions) is just how much protection/overhead Guile should try to
provide by default.

> (Oh, and to bring this slightly back on-topic, I'm imagining that if
> streams or lazy stuff throw off quite a few forced promises then it's
> a good thing for them to be small and fast.)

Quite possibly.  

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel