[mpi-21] Ballot 4 - Re: Request for interpretation
Bronis R. de Supinski
bronis at [hidden]
Thu Jan 31 05:36:58 CST 2008
Your new wording works for me.
On Thu, 31 Jan 2008, Rolf Rabenseifner wrote:
> I try to summarize all 3 replies in one proposal:
> MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read:
> If a function does not recognize a key,
> it will ignore it, unless otherwise specified.
> If an implementation recognizes a key but does not recognize
> the format of the corresponding value, the result is undefined.
> but should read:
> An implementation must support info objects as caches for arbitrary
> (key, value) pairs, regardless of whether it recognizes the pairs.
> Each MPI function which takes hints in the form of an MPI_Info must
> be prepared to ignore any key it does not recognize.
> Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new
> Advice to implementors.
> Although in MPI functions that take hints in form of an MPI_Info
> (e.g., in process creation and management, one-sided communication,
> or parallel file I/O), an implementation must be prepared to ignore
> keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS,
> MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the
> implementation must retain all (key,value) pairs so that layered
> functionality can also use the Info object.
> (End of advice to implementors.)
> Rationale for this clarification:
> The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET,
> MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs
> that are not recognized in routines in other chapters that
> take hints with info arguments.
> The proposed clarification is necessary when we assume, that
> layered implementation of parts of the MPI-2 standard should
> be possible and may use the MPI_Info objects for their needs.
> This was a goal of the MPI-2 Forum and the MPI-2.0 specification.
> Bronis, for me, your wording "an MPI implementation may restrict" was
> in conflict with the rest of the advice. I hope the formulation above
> is also okay. It is based on the new wording from you and Dick in first
> part of the proposal.
> Best regards
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> mpi-21 mailing list
More information about the Mpi-21