[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: condition system proposal
From: |
Christophe Rhodes |
Subject: |
[Gcl-devel] Re: condition system proposal |
Date: |
Tue, 5 Nov 2002 10:07:20 +0000 |
User-agent: |
Mutt/1.4i |
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)