From: "Rolf Rabenseifner" Date: January 31, 2008 4:25:46 AM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Reply-To: "Mailing list for discussion of MPI 2.1" 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@XXXXXXX 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@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21