[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What are the arguments in favor of delay/force in eval.c?
From: |
Rob Browning |
Subject: |
Re: What are the arguments in favor of delay/force in eval.c? |
Date: |
Wed, 07 Dec 2005 16:52:30 -0800 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
Kevin Ryde <address@hidden> 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