[mpi-21] Ballot 4 - Re: Request for interpretation

[Bronis R. de Supinski]

Rolf:

Your new wording works for me.

Bronis

On Thu, 31 Jan 2008, Rolf Rabenseifner wrote:

> I try to summarize all 3 replies in one proposal:
>
> ___________________________________
>
> 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
> paragraph:
>    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
> Rolf
>
>
> 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
> mpi-21_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
>