Date: Mon, 23 Oct 1995 17:09:45 +0059 (PDT)
From: Richard Frost <frost@SDSC.EDU>
Subject: Re: mpi-io, mpi-dynamic generalizations
To: mpi-io@nas.nasa.gov, mpi-dynamic@mcs.anl.gov, mpi-core@mcs.anl.gov
Thanks for the quick responses and discussion.
Here's some detail, and an MPI_2 proposal. Perhaps there are
other approaches?
client
...
MPI_Type_commit( &utype );
...
MDIO_write( server, utype );
...
server
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
following:
~MPI_Type_Attribute( MPI_Datatype utype, MPI_DataAttr description )
where
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) ..."
elem.label_length
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
party transfers.
I'm interested in knowing what other kinds of attributes are
useful to users and library writers.
Richard Frost
SDSC
------- End of Forwarded Message