[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
looping in unwind-protect cleanups
- To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
- Subject: looping in unwind-protect cleanups
- From: firstname.lastname@example.org (Jon L White)
- Date: Thu, 14 May 87 10:24:36 PDT
- Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
- In-reply-to: David A. Moon's message of Thu, 14 May 87 00:57 EDT <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Re: . . . let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
. . .
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
A lock is effectively 1 bit per catch, and by storeing it in the catch
frame, it is process-specific; lock-acquisition would be done in THROW,
and is very low overhead. I suspect these two proposed implementations
are isomorphic at a fundamental level, with your "validity bit" replaceing
The only thing that seems a bit peculiar in your review of the new Symbolics
code is that the error signalled by "failure to acquire the lock" has to be
treated specially (not caught by IGNORE-ERRORS, goes directly to BREAK,
"does not pass GO, lands in jail", whatever). Maybe that is the reason RAM
and some others were so upset by the original proposal. I think I see the
point of the special handling; but I don't like the singularity.
-- JonL --