Date: Mon, 23 Oct 1995 17:09:45 +0059 (PDT)
From: Richard Frost <frost@SDSC.EDU>
Subject: Re: mpi-io, mpi-dynamic generalizations
To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Thanks for the quick responses and discussion.
Here's some detail, and an MPI_2 proposal. Perhaps there are
MPI_Type_commit( &utype );
MDIO_write( server, utype );
MDIO_read( client, sometype );
When "server" has no previous knowledge of "utype" (the client is a
new application), then "MDIO_write" need to send a facimile of the utype
struct (not the data) so that "MDIO_read" can instantiate one.
In MPI_1, MPI_Datatype_"whatever"() stores no information about the
data types, just relative binary addressing. This in effect assumes
that the code defining a type is compiled for all participants. Not
so in dynamic information services.
If not already proposed in MPI_2, I propose (and will implement) the
~MPI_Type_Attribute( MPI_Datatype utype, MPI_DataAttr description )
description is an array of structures, one for each element
of utype. For example
elem.type -- a previously defined MPI type
elem.label -- a descriptive string, perhaps
"Content/Type keyword(s) ..."
The data generated here would be either inserted in the existing
(uncommitted) type, or (barf) placed in a separate structure.
The former affords more transparency to the user.
In either case, the type can be transmitted down the wire. A receiver
could rebuild and instantiate the type without knowing the application
source code. All of the MPI and MPI-IO functionality can then be brought
into play. This is an extremely useful capability when performing 3rd
I'm interested in knowing what other kinds of attributes are
useful to users and library writers.
------- End of Forwarded Message