I think David is right with regard to the datatype constructors from
the I/O chapter. They are not fundamental datatype constructors,
but they are provided for user convenience. They are entirely
implementable (and will probably be implemented) using MPI-1
fundamental datatype constructors.
Therefore, I do not think these datatype constructors should be
returned as part of the MPI_GET_TYPE_ENVELOPE.
Jean-Pierre
PS: By the way, according to Jeff Squyres, all interfaces from
MPI-2 should adopt common naming conventions, and get/set
interfaces should adhere to the convention: MPI_object_action_subset.
If this is true, shouldn't the name be MPI_TYPE_GET_ENVELOPE
rather than MPI_GET_TYPE_ENVELOPE ? Comments ?
----------Forwarding Original Note --------
To: lederman @ cs.wisc.edu
cc: mpi-external @ mcs.anl.gov
From: taylor @ think.com
Date: 10/23/96 01:59:10 PM AST
Subject: Re: summary, changes to chapter - resend
Security:
--0__=d2GcUpaPfXDuTr1tj7hRoMlsB4Un2yPZmJnF1zLZA88djyHFw9PdhQ0u
Date: Wed, 23 Oct 1996 11:03:44 -0500
From: Steve Huss-Lederman <lederman@cs.wisc.edu>
(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.
--0__=d2GcUpaPfXDuTr1tj7hRoMlsB4Un2yPZmJnF1zLZA88djyHFw9PdhQ0u--