Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!gnelson
From: gnelson (Greg Nelson)
Newsgroups: comp.lang.modula3
Subject: Re: running out of memory
Message-ID: <9102120059.AA15796@jumbo.pa.dec.com>
Date: 12 Feb 91 00:58:51 GMT
Lines: 57
In-Reply-To: Message of 8 Feb 91 17:42:23 GMT
    from doug@snitor.uucp (Doug Moen)
    <jr5onv9pm@snitor.uucp>
To: m3
Cc: doug@snitor.uucp (Doug Moen)
X-Folder-Carbon: sent


Doug Moen proposes that Modula-3 define an exception to be raised by
NEW when storage is exhausted, arguing that this is necessary in order
to write robust programs, such as a text editor that saves edits when
storage is exhausted.

Eliot Moss and Mick Jordan point out that if this approach is used
to provide robust programs, it should probably be extended to many
other checked runtime errors, perhaps to all of them.

With this approach, the main body of, say, a robust text-editor would
use a TRY-EXCEPT:

TRY
  <main body of text editor>
EXCEPT
  RunTimeError(ErrCode) =>
    Wr.PrintText(Stdio.stderr, CodeToMessage(errCode));
    Wr.PrintText(Stdio.stderr, "Saving edits...");
    <save edits>
END

Of course, as Dave Emery points out, <save edits> has to be coded very
carefully (for example, it must not allocate any storage).  In fact,
Wr.PrintText might allocate storage, so the TRY-EXCEPT-ELSE code above
is useless as it stands.  But we can imagine providing a very robust
library procedure that prints a TEXT on Stdio.stderr without allocating
any storage or depending on anything except the very lowest levels
of the runtime system, and use it instead of Wr.PrintText.

A more serious problem with the approach is that Modula-3 programs
are multi-threaded.  The TRY--EXCEPT--END construct above has to be
wrapped around every thread, not just the main thread, since storage
exhaustion could happen anywhere in the program.  

The programmer writing the text editor can wrap the TRY--EXCEPT--END
around all the threads forked directly by his program, although he
might complain that this is awkward.  But even this is not enough,
since library packages fork background worker threads.  For example,
the Trestle window system forks two threads to buffer the queue of
events from the X server.  The Trestle implementation can hardly be
expected to wrap the TRY--EXCEPT--END code around the threads that
it forks, since the action <save edits> is entirely foreign to Trestle.

The solution to these problems is to provide an interface through which
clients can register procedures to be executed when a program aborts
due to a checked runtime error.  A text editor could register a
procedure that saves the edits.  An elevator control program could
provide a procedure that stops the elevator by the most primitive
mechanism available.  A program development environment could enter
the debugger.  The design of this interface is quite system-dependent,
as these examples suggest, but it should not be difficult to provide
a single interface that works in, say, all standard Unix environments.
SRC Modula-3 does not yet provide such an interface, but Eric Muller
tells me that one is on the way.

Greg Nelson