I have been thinking over the discussion of the last day. I would
like to update the chapter with what I think is the best way. Since
we are nearing the SC96 deadline (yes, even I, the editor, have to
live with it), I wanted to sumarize my proposed changes:
- I plan to remove 125/41-43 (advice to users) that MPI_LB and MPI_UB
are not returned. I will add to 125/32:
MPI_BASIC a basic datatype including MPI_LB and MPI_UB
I beleive this requires the behavior Rajeev wanted where a struct has
a MPI_UB and you want it included in the count.
- The text will be changed to indicate that when you give a basic
datatype to MPI_GET_TYPE_CONTENTS it must return a value where if you
do a comparison to predefined ones in mpi.h/mpif.h you get true for
the correct one. Everyone seems to want that. To make this clean
(see Lloyd's concerns about giving copies not pointers), I will add a
datatype comparison function for basic datatypes. Using == will not
return true. This is consistant with what we do with MPI_COMM_COMPARE
in MPI-1.
- I think I will say that MPI_GET_TYPE_CONTENTS returns a handle
that you must free. This avoids the problem of threads and getting
the original datatype freed from under you. Having a comparison
function eliminates the problem of getting different handles. I was
starting to dislike returning the same handle for other reasons. If
you use the create/free semanitics like we normally do, it raises the
problem that if you get back a basic datatype you now need to free
it. This would be different.
- As for 126/2-3. If we restrict the datatypes returned by
MPI_GET_TYPE_ENVELOPE to not include the I/O datatypes then you have a
situation where you will not get back the original calling tree that
created the datatype. As currently defined, the routines in I/O
return a new datatype and are not different from any other dataype. I
appreciate David's point, but I think it may be cleaner to also return
a unique value for all new datatype constructors. It is only a couple
of new values. My view is that if we adopt them as part of MPI-2 then
they are new constructors and we treat them the same as any other.
- As for Lloyd's point that you now need to keep around the uncomitted
datatype: I agree. I brought this up several times and everyone
seemed to think this is fine. It still allows the optimizations to
occur in the committed version but does not allow the implementation
to free up the space of the uncommitted version.
- I need to fix up MPI_IDO presented on p. 110. It is wrong. It
should not have status since this is done at the wait/test. It has
been noted privately to me that MPI_IDO is similar to MPI_START. I
agree. I will change the text to say you use MPI_START and allow
non-persistant handles to that function (only the ones specified). I
will note the alternative of using a separate function and still
limiting Start to persistant requests. I do not view this as a major
change/issue. We can switch it later if people want.
As always, I welcome feedback. I don't want to change the chapter
unless people think it is a good idea.
Steve