[Gcl-devel] Re: condition system proposal

[Christophe Rhodes]

On Tue, Nov 05, 2002 at 10:56:15AM +0100, Peter Wood wrote:
> Hi,
> > > You've gotta respect how essentially robust GCL is.  Neither CLISP's
> > > nor Lispworks' (trial edition) 'ignore-errors will handle the last
> > > example.  CMUCL (presumably) continues 'forever'.  Only SBCL comes
> > > close to doing 'the right thing', but incorrectly calls the error
> > > condition a simple-error when this
> > > 'SB-KERNEL:%DETECT-STACK-EXHAUSTION' surely should signal a
> > > storage-condition (IMHO ;-))
> > 
> > You're quite right, and in versions more recent than sbcl-0.7.5 it
> > does signal a storage condition (as well as being signalled by a
> > different mechanism).  Your other point is right, too; a
> > storage-condition is not of type error, and hence should not be caught
> > by ignore-errors.
> Yes.  I bit my tongue _as_ the mail was going out.  I have defined a
> condition for ansi GCL (not in CVS) called simple-storage-condition
> (should be simple-storage-error) which inherits from storage-condition
> and simple-error.  This gets caught by ignore-errors.  This is
> permissable, right? Advisable?

Permissible, yes.

As for adviseable, here's the reason that sbcl doesn't do that:

The stack overflow control in SBCL is implemented by having an
mprotect()ed region at the end of the control stack; when transfer of
control tries to allocate a new stack frame, the process receives a
sigsegv and control goes to a handler, which returns control to lispland
with an error.

But, where does this new control allocate its stack frame? Well, it has
to un-mprotect() the guard page, so essentially while you're in the
error handler you have no protection at all.  Hence, it would be bad if,
say, a user wrote
  (handler-case (infinite-recursion-oops)
    (error (c) (do-some-complex-recovery c)))
and the do-some-complex-recovery thing, expecting some simple lispland
error, instead found itself walking off the end of the control stack
causing complete death of the lisp environment.

I think that's what the CLHS is referring to when it talks about
implementation limitation, rather than lisp programming error; if we
had infinite RAM, storage-condition would never be signalled; it's
qualitatively different from, for example, (package-name "foo") where
"foo" does not name a package :-)

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)