<html><body>
<p>Your wording works for me Rolf. -- Thanks<br>
<br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-21-bounces@cs.uiuc.edu wrote on 01/31/2008 05:25:46 AM:<br>
<br>
> I try to summarize all 3 replies in one proposal:<br>
> <br>
> ___________________________________<br>
> <br>
> Proposal:<br>
> MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read:<br>
> If a function does not recognize a key, <br>
> it will ignore it, unless otherwise specified.<br>
> If an implementation recognizes a key but does not recognize <br>
> the format of the corresponding value, the result is undefined.<br>
> but should read:<br>
> An implementation must support info objects as caches for arbitrary<br>
> (key, value) pairs, regardless of whether it recognizes the pairs.<br>
> Each MPI function which takes hints in the form of an MPI_Info must<br>
> be prepared to ignore any key it does not recognize.<br>
> <br>
> Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new<br>
> paragraph:<br>
> Advice to implementors.<br>
> Although in MPI functions that take hints in form of an MPI_Info<br>
> (e.g., in process creation and management, one-sided communication, <br>
> or parallel file I/O), an implementation must be prepared to ignore <br>
> keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS, <br>
> MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the <br>
> implementation must retain all (key,value) pairs so that layered <br>
> functionality can also use the Info object.<br>
> (End of advice to implementors.)<br>
> _____________________________<br>
> Rationale for this clarification:<br>
> <br>
> The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET,<br>
> MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs<br>
> that are not recognized in routines in other chapters that<br>
> take hints with info arguments.<br>
> The proposed clarification is necessary when we assume, that <br>
> layered implementation of parts of the MPI-2 standard should <br>
> be possible and may use the MPI_Info objects for their needs.<br>
> This was a goal of the MPI-2 Forum and the MPI-2.0 specification.<br>
> ___________________________________<br>
> <br>
> Bronis, for me, your wording "an MPI implementation may restrict" was<br>
> in conflict with the rest of the advice. I hope the formulation above<br>
> is also okay. It is based on the new wording from you and Dick in first <br>
> part of the proposal.<br>
> <br>
> Best regards<br>
> Rolf<br>
> <br>
> <br>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<br>
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<br>
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<br>
> _______________________________________________<br>
> mpi-21 mailing list<br>
> mpi-21@cs.uiuc.edu<br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a><br>
</tt></body></html>