Correction to last message on memory

[Mark S. Miller <mark>]

Date: Tue, 27 Jun 89 13:28:04 PDT
   From: eric

   Having just looked at the bomb code, and finding it to not do any allocation,
   the first part of my last message is voided.  I still like the idea of using
   the blast shield to invoke VM.


I think this would be a bad idea.  We (thankfully) have a
termination-oriented demolition package, as opposed to an optionally-
recover-and-continue package.  (The original Bill Miller (?) package
in the blue book (the '88 C++ Proceeding) is of the latter sort) There
is no reason to destroy the computation which is trying to obtain
memory in order to invoke the grim reaper.  Rather this should be in
the low level memory allocator itself, as it was in the 88.1 design:

char * operator new (unsigned long size)
{
    char * result;
    
    while (! (result = malloc (size))) {
	grimlyReap ();
	/* returns only after it has reclaimed something.  If there is */
	/*  nothing TO RECLAIM, IT BLASTs. */
    }
    return result;
}

The only reason I can think of to use BLAST_SHIELDs instead of the
above is to be able to specify by *dynamic* scope what procedure to
invoke to grimly reap.  Note that BLAST_SHIELDs are dynamically scoped
in *precisely* the same way as fluid variables, so:

/* We make this a deferred class instead of a pointer to function */
/*  so that it may carry state.  Other than that it is */
/*  conceptually a pointer to function */

CLASS(GrimReaper,Object) {
  DEFERRED:
    virtual void reap ()	DEFERRED_SUBR;
};


/* The fluid variable designating the current grim reaper */

DESIGN_FLUID(GrimReaper *,grimReaper);

...
   {
	FLUID_BIND(GrimReaper *,grimReaper,flushSnarfsOrSomething);
	/* flushSnarfsOrSomething is now the current grim reaper */
	...
	... NEW(Foo()) ...
	...
   }
...



char * operator new (unsigned long size)
{
    char * result;
    
    while (! (result = malloc (size))) {
	FLUID_VAR(grimReaper)->reap ();
    }
    return result;
}


In other words, fluidly bound procedures can do everything that
resumable error handlers can do, and are much cleaner.  Instead of
raising a resumable error, one just invokes a fluidly bound procedure.
If this procedure decides that this condition cannot be "resumed",
then it simply BLASTs to terminate out to a "true" exception handler.
The reason this is cleaner than optionally-resumable-error-handlers is
that we always know that a BLAST doesn't return, and a procedure call
may.