Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.lang.modula3
Subject: Re: checked run-time errors and exceptions (was: running out of memory)
Message-ID: <44466@nigel.ee.udel.edu>
Date: 12 Feb 91 20:19:55 GMT
References: <9102111557.AA02459@ibis.cs.umass.edu> <1991Feb11.152850.1851@src.dec.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 17
Nntp-Posting-Host: snow-white.ee.udel.edu

In article <1991Feb11.152850.1851@src.dec.com> mjordan@src.dec.com (Mick Jordan) writes:
>Although running out of memory is not a programming error, it is
>effectively a failure of the Modula-3 abstract machine, and I am curious to
>know how you can write portable code to recover from it, given that you must
>be very careful not to call any code which might call NEW again.

When I've needed to do such a thing, I've allocated space at the start
of execution, and when malloc() returned NULL, I freed that space and
cleaned up. Hence, the cleanup code could reuse that space to recover.
Of course, how much space to initially allocate is problematic, but
since I was using C it wasn't too hard to handle.  Surely this is already
handled in Smalltalk, C, Ada, etc.  Why would Modula-3 be so different?
-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=