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

[Rob Ross]

This is excellent. -- Rob

On Jan 31, 2008, at 4:25 AM, 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
>