> 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.
The reason the "size" field was made opaque in MPI-1 was that
implementations may put different information into it. They may stick
in this field the size sent on the wire. This could be bytes,
multiples of datatype, etc. Thus, we did not want to make this field
visible. This is why the set function. I think there was also a
similar thing about cancel but am not recalling the details. I think
this decision was made in MPI-1 and I am inclined to stick with it for
> MPI_REQUEST_TYPE: A very poor name. Makes me think that it returns the
> MPI_Datatype associated with a request.
I noticed this. Those more creative than I: a suggestion for a new name?
> 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.
I noticed that too. My concern is that we now cache on datatype and
comm. We need to keep them straight. I noticed that the low level
datatype decoding uses TYPE here. I am open to thoughts but am
inclinded to keep it as it is until something better is suggested. I
run out of ideas as time goes by. I would probably just give a child
the name CHILD_X :-)
> 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?
I'm not sure that all implemenations do nothing here. I think some
search for what is really contiguous data even if it was not declared
this way and makes it so for sending. Thus, I think there is a use