RE: low level datatype accessing

Lewins, Lloyd J (llewins@msmail4.hac.com)
23 Oct 1996 08:20:08 -0800

Steve Wrote
"As long as we are discussing this issue, I will raise two other points
that are discussion items this section. First, when you get back a
basic datatype can you tell what type it is? I don't think we say
that the handle you get back from this function is the same. For
example, if the type is MPI_INT will the handle you get back be the
same as the predefined one so you can do a comparison. You will need
to know what the datatype is to encode it with a different scheme then
the ones provided."

The existing semantics for handles (MPI-1, section 2.4.1, page 9 line 18-26)
leads to the conclusion that the handle you get back from such a function
would NOT be the predefined one.

"The intended semantics of opaque objects is that each opaque object is
seperate from each other; each call to allocate such an object copies
all the information required for the object."

Thus, the type constructor calls may well create copies of the types, and will
not be able to return the original (predefined type) later.

Thus, rather than comparing handles for equality, we should be using a
function which determines if two types are "substantially equal". For
simplicity, but not orthogonality, we could limit such a function to basic
types only.

Steve wrote:
"Second, what are the array_types returned? Is it just a pointer to the
handle or a new handle? That is, does the user have to free it?"

I think this question is phrased wrongly. The question is whether a new type
is returned, or just a handle to an existing object. If the former, then the
object must be free'd by the user. If the later, we need to add to the MPI
handle semantics a statement like the following:

"Two handles to the same opaque object are equivelent when compared using
the equality operator."

This whole thread is altering the semantics of these functions substantially.
The functions were originally carefully defined to return types and values
which could be used to recreate an equivelent to the original type. This is
important for implementations which flatten datatypes, or otherwise discard
superfluous information (extra UB and LB markers).

If we change the semantics so that the information returned is the same
datatypes as were originally used to create the datatype we have the following
impact:

a) If the implementation flattens a type when it is committed, or otherwise
substantially changes its representation, it will now have to carry around the
original datatypes just in case the user ever calls these functions.
b) We change the internal semantics so that the implementation MUST use
reference semantics not copy semantics, so that it can return the original
types.

Lloyd Lewins
llewins@msmail4.hac.com
Hughes Aircraft Co.