From: Richard Treumann <treumann@XXXXXXXXXX>
To: <mpi-comments@XXXXXXXXXXXXX>,<mpi-core@XXXXXXXXXXX>
Subject: Re: MPI_ALLOC_MEM & no mem
Date: Mon, 3 Aug 1998 11:41:07 -0400
MIME-Version: 1.0
Content-Type: text/plain
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: ab2b52466824ff827bf2c38b06349bff

I see that most Forum members who responded prefer the malloc model for
MPI_ALLOC_MEM.  I do too at this point but it looks to me like the standard, as
written, rules it out.  I think MPI_TRYALLOC_MEM with an additional flag output
would be better if we could do it over but we cannot.

 It is not clear to me why Raja tells Eric that advising the user to check the
returned baseptr for == NULL will not work.  We have already introduced at
least one case where the standard says a user's not getting all she asked is
*not really* an error.  The user who reads from a file is advised that she may
get no data and still have an MPI_SUCCESS return code if the read is past
end_of_file.  The user is advised to check how much data was actually read if
going past  end_of_file is possible.

I suggest that the description of MPI_ALLOC_MEM say something like this:

"the basptr will be returned as NULL if sufficient  memory is not available.
MPI_MEM_ALLOC will never return a MPI_ERR_NO_MEM class error code when it might
be possible to satisfy some smaller request."

I considered  " will never return a MPI_ERR_NO_MEM class error code." but some
implementation might really be returning "special memory" and only be able to
do so if some precondition is met, like an environment variable set to
pre-construct a pool of "special memory".  If there is a situation where even
the smallest request would fail then maybe it is a NO_MEM error.

Raja suggests reviving the discussion of "recoverable errors".  I do not want
to go anywhere near that one. It was a quagmire when we were meeting face to
face and  I do not want to try to define it in errata or even MPI 2.1.   I do
not know where the material that was dropped from the standard went if it did
not get to the JOD.

                 Dick

Dick Treumann                IBM RS/6000 SP Development
Tele (914) 433-7846         Fax (914) 433-8363