(This is an updated version of my previous message. I don't think
anyone got the old one due to a machine crash.)
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
Good.
I beleive this requires the behavior Rajeev wanted where a struct has
a MPI_UB and you want it included in the count.
Agreed.
[...]
- 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.
If all the datatype constructors are fundamental datatype constructors,
then the ones in the i/o chapter are not implementable in a layered
implementation of the i/o chapter.
A layered implementation cannot change the way mpi stores datatypes,
hence get-type-envelope and get-type-contents will know nothing about
the new constructors, and therefore the layered library cannot create
new fundamental datatype constructors -- it can only add convenience
datatype constructors. Did I miss something?
[...]
Thanks.