Re: new partial version of chapter

Eric Salo (salo@mrjones.engr.sgi.com)
Fri, 31 Jan 1997 14:49:06 -0800

MPI_STATUS_SET_ELEMENTS and MPI_STATUS_SET_CANCEL: These routines looks fine,
but do we really want them? The position that we appear to be taking in MPI-2
is that anything new which involves the MPI_Status object will require a new
function. This seems silly, since it's already semi-transparent. Wouldn't it be
cleaner just to define a 'byte_count' field and an 'is_cancelled' field? This
information must be in there somewhere already, after all.

Page 5, line 33: MPI_ICOMM_GET_ANME looks like an interesting function name but
my guess is that it's just a typo.

MPI_TYPE_ENVELOPE: Assuming that MPI_TYPE_INDEXED_BLOCK() survives the next two
meetings, we'll need to add a MPI_INDEXED_BLOCK constant.

MPI_REQUEST_TYPE: A very poor name. Makes me think that it returns the
MPI_Datatype associated with a request.

MPI_DATATYPE_*: Even though the proper name of the object is MPI_Datatype, all
of the MPI-1 routines just use TYPE in their names instead of DATATYPE. So I
would suggest that we follow that convention here.

Regarding the comments about MPI_TYPE_COMMIT on the last page: I believe that
the current text is as it should be, but I have a related question: Are there
implementations out there which really do perform non-trivial optimizations
when they commit datatypes? Could we get away with deprecating MPI_TYPE_COMMIT?

-- 
Eric Salo         Silicon Graphics Inc.             "Do you know what the
(415)933-2998     2011 N. Shoreline Blvd, 8U-802     last Xon said, just
salo@sgi.com      Mountain View, CA   94043-1389     before he died?"