Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!satisfied.elf.com!news.mathworks.com!newshost.marcam.com!charnel.ecst.csuchico.edu!waldorf.csc.calpoly.edu!kestrel.edu!mcdonald
From: mcdonald@kestrel.edu (Jim McDonald)
Subject: Re: Lucid Lisp error type question
Message-ID: <1995Jan19.015047.1731@kestrel.edu>
Sender: mcdonald@saker.kestrel.edu (Jim McDonald)
Nntp-Posting-Host: saker.kestrel.edu
Organization: Kestrel Institute, Palo Alto, CA
References:  <RLEE.95Jan17133004@nlp.vienna.itd.sterling.com>
Date: Thu, 19 Jan 1995 01:50:47 GMT
Lines: 71

In article <RLEE.95Jan17133004@nlp.vienna.itd.sterling.com>, rlee@vienna.itd.sterling.com (Richard Lee) writes:
|> Question:
|> What error type does Lucid Common Lisp produce when GC fails -- ie,
|> recovers so little garbage that it has to leave GC and EGC turned off?
|> 
|> Details:
|> I am developing a program which processes messages as they come into the
|> system.  The program uses ignore-errors so that if an error occurs while
|> processing a message it simply logs the error and proceeds to the next
|> message.  My problem is that for _some_ errors, such as GC failure, the
|> program should gracefully terminate instead of proceeding.  I can use
|> (typep error ...) if I know exactly _what_ type to check for -- eg, I
|> could detect a division by 0 error by checking for 'DIVISION-BY-ZERO:
|> 
|> > (/ 3 0)
|> >>Error: Attempt to divide by zero: (/ 3 0).
|> 
|> /:
|> :A  0: Abort to Lisp Top Level
|> 
|> -> :a
|> Abort to Lisp Top Level
|> Back to Lisp Top Level
|> 
|> > (defun my-div (x y)
|>     (multiple-value-bind (result error) (ignore-errors (/ x y))
|>       (if (typep error 'DIVISION-BY-ZERO)
|> 	  "You can't divide by 0!"
|> 	  result)))
|> 
|> MY-DIV
|> > (my-div 3 2)
|> 3/2
|> > (my-div 3 0)
|> "You can't divide by 0!"
|> 
|> I hope I've adequately described what I'm looking for.  Any help greatly
|> appreciated.

I don't have the answer you need offhand, but conceptually the out-of-space
errors are generated in two steps.  The first error occurs when GC discovers
it cannot get enough memory to copy the dynamic semi-space.  In that case
it gives you the option of aborting right then or of continuing to cons into
the other semi-space, with no hope of surviving the next GC.  If you opt for
the latter you can run until the next full GC, at which point the program
must abort.  (I don't remember if the first error is smart enough to let 
you try GC again after killing some other Unix processes to get more space.)

As a minor historical note, my suggestion for the text of the continuation 
option for the first error was: "You won't be sorry now, and you won't be 
sorry tomorrow, but you'll be sorry later, and for a long, long time.", but 
marketing insisted on something more prosaic.  [Similarly, my proposed and 
vetoed error msg for the stack being trashed was "Toto, I don't think we're
in Kansas anymore."]

You might find what you want in the Advanced User's Guide, or by simply
forcing an image to run out of space while tracing SIGNAL, or ERROR, or
whatever is appropriate for your release.  (It might or might not die
some freakish death in such cases, because a small amount of space is
reserved for consing during GC itself, and any consing caused by the
tracing might or might not be allocated from that and if so, might or
might not exceed it.)

Also note that there are many ways to get into trouble with space (can't 
copy dynamic semi-space, can't allocate space for <your favorite space>, 
GC within GC, bad pointer found, etc.) so presumably there is a hierarchy
of memory error types.

Sorry I couldn't be more precise from memory.

 
