I'm glad you have taken the time to follow up on your questions and
put them directly to the external group from MPI-IO. Though I'm not
the expert on these areas, I'll put in my 2 cents. I encourage others
to jump in since I am in the process of updating the external chapter.
The question was asked as to why STRUCT is included in the list of
restricted types that can be sent portably around machines. It is
not, as far as I know, to deal with 32 vs. 64 bit word sizes. When
you reuse a datatype on a node with a different word size, it will
automatically get the new data size. The issue is a struct may be a C
struct like:
struct test {
int i;
char c;
int j
};
Different machines may use different padding schemes for the char.
They may work align them all or not. It may depend on compiler
options. Thus, the receiver can reproduce the struct on the sender
but this may differ from the struct on the reciever. The problem is
that MPI_TYPE_STRUCT has an array_of_displacements. Once you create
the MPI struct to represent the C struct, you lose the high level
information which would allow the system to change the displacements
accordingly.
Another question was about deciding between top-level and bottom-level
entries in the search/decode functions for datatypes. I think this
was to make it easier on the implementors. I think it is a good point
that users want to know what they will get. Do implementors care if
one is choosen and if so can we still just pick one and rule out the
other?
A question about the attribute string: Is the intention that when you
decode a datatype that the attribute stay with the datatype? There is
a mechanism to cache on a datatype in MPI-2 but it does not get
transfered in any way.
Steve