From: Raja Daoud <raja@XXXXXXXXXXXXXXX>
Subject: Re: MPI_ALLOC_MEM & no mem
To: salo@XXXXXXX
Date: Mon, 03 Aug 1998 0:43:48 CDT
Cc: mpi-comments@XXXXXXXXXXXXX,mpi-core@XXXXXXXXXXX
In-Reply-To: <9808020609.ZM22408@XXXXXXX>
X-Mailer: Elm [revision: 111.1]
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: 4565c848f4a56bbfd8f46db46dc13d32


>   5- Document that a value of NULL returned from MPI_Alloc_mem() is in fact
>      *not* an "error", it is rather the way in which MPI successfully tells

This wouldn't work for the default error handlers.  I think users want
the NULL to be mapped to an auto-abort error in this case.



MPI's quality-of-implementation position is broad and has served
implementors well, providing a good shield, letting us deal with our
"fear, uncertainty, and doubt" at the expense of added value to the
users.  I don't want to remove it, I think it still has a good function
to play in several cases.

At the same time, several years have passed since MPI-1.  The public
implementations have matured, and most if not all vendors have mature
implementations as well.  I think we have learned that we can provide a
good QoI level to users, without fear of seriously impacting performance
or complexity of implementation.  I think by far most MPIs provide a
high level of error detection, and continuation from most of these
errors.

So we're at a point where implementations provide users extra value that
cannot be safely used because it's theoretically not portable.  It would
be nice if we pass this value on to users, with our thanks for putting
up with the sweeping impact of the QoI clause :-).  This would allow ISVs
to write more sophisticated code that can deal with a wider scope of
resource limitation problems.

There are a few approaches to do this, without adding new routines for
each case:

- Update the MPI standard to reflect this higher level of error handling.

- Implementors reach a QoI agreement independent of the MPI standard and
  publish it for ISVs to feel safe about portability.

- Let ISVs discover (maybe with some help from implementors) that they
  can portably get away with many instances of error continuation, thus
  establishing a de-facto higher QoI level as their applications are
  ported to other systems.

This last scenario is where we're currently heading.  It's not a very
efficient model and introduces unnecessary uncertainty for users, with
some people saying "it's erroneous code," and others saying "just do it,
it works in real life."

Without changing implementations, and just added text to document the
current common-denominator QoI level, we can say:  if you detect an
error case from that small list, it must be continuable."

This doesn't mandate you have to detect it (still a big protection), and
if you do, just make sure the if() is upstream in the code (chances are
it's already there if the case is on the small list).


--Raja

-=-
Raja Daoud				Hewlett-Packard Co.
raja@XXXXXXXXXX				http://www.hp.com/go/mpi