<html><body>
<p>IBM long ago chose the real-politic approach of supporting both interpretations. By default we restrict INFO objects to key:value pairs that mean something to our functions that take INFO arguments and quietly discard key:value pairs we do not recognize. As far as I know this has not been a problem for anyone writing portable MPI applications. <br>
<br>
I can see that hint filtering would restrict someone who wants to use an INFO for layered libraries. For that reason, any user who wishes to use an INFO object as a general purpose cache for key:value pairs that mean nothing to our MPI implementation can set an environment variable or command line option (MP_HINTS_FILTERED/-hints_filtered = no) and get the behavior Linda was expecting.<br>
<br>
I do have any problem with clarifying the standard to say that an MPI_Info object should be prepared to manage unrecognized key:value string pairs. I suggest changing:<br>
<br>
==============<br>
<font size="4">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. </font><br>
<br>
to<br>
<br>
An info object is a cache for arbitrary <font size="4">( key, value) pairs. Each MPI function which takes hints in the form of an MPI_Info must be prepared to ignore any </font> <font size="4">key it does not recognize.</font><br>
<font size="4">============</font><br>
<br>
<font size="4">I think this approach implies that any statements about what happens when a recognized </font><b><font size="4">key</font></b><font size="4"> has a garbage </font><b><font size="4">value </font></b><font size="4">belong with the function that recognizes the key.</font><b><font size="4"> </font></b><font size="4">By insulating the info description from the descriptions of particular MPI functions that take MPI_Info hints, we leave people the option of using info objects as hints for third party libraries that work with MPI but are not part of the MPI API.</font><br>
<br>
Dick <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/30/2008 12:33:34 PM:<br>
<br>
> This is a proposal for MPI 2.1, Ballot 4.<br>
> <br>
> I'm asking especially <br>
> Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud,<br>
> the participants of the email-discussion in 1999, to review this proposal.<br>
> <br>
> This is a follow up to:<br>
> What info keys can be set? <br>
> in </tt><tt><a href="http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-">http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-</a></tt><tt><br>
> errata/index.html<br>
> with mail discussion in<br>
> </tt><tt><a href="http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-">http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-</a></tt><tt><br>
> errata/discuss/infoset/<br>
> ___________________________________<br>
> Background:<br>
> The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38<br>
> <br>
> "If a function does not recognize a key, it will ignore it, <br>
> unless otherwise specified."<br>
> <br>
> was interpreted in two different ways:<br>
> 1. This sentence is only valid in the routines in other chapters<br>
> (e.g. processs creation and management, one-sided communication, <br>
> parallel file I/O) where infos may be used to specify portable<br>
> and implementation defined hints.<br>
> 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET,<br>
> MPI_INFO_GET, and MPI_INFO_DUP.<br>
> The following proposal ist based on Option 1.<br>
> Option 2 is rejected due to the reason shown after the proposal.<br>
> ___________________________________<br>
> <br>
> Proposal:<br>
> MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read:<br>
> If a function does not recognize a key, <br>
> it will ignore it, unless otherwise specified.<br>
> but should read:<br>
> If a function in another section of the MPI standard <br>
> does not recognize a key, <br>
> it will ignore it, unless otherwise specified.<br>
> The routines in this section. <br>
> The functions in this section must not ignore any (key,value) pair. <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>
> For optimization, an MPI implementation may already sort out<br>
> which (key,value) pair can be recognized for use in other chapters<br>
> (e.g., in processs creation and management, one-sided communication, <br>
> parallel file I/O) to guarantee a fast access to the appropriate<br>
> information when used in routines of those chapters.<br>
> For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY,<br>
> MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation<br>
> must still keep also all other (key,value) pairs that cannot be<br>
> recognized by that MPI implementation. <br>
> (End of advice to implementors.)<br>
> ________________________________<br>
> Rationale for this clarification:<br>
> <br>
> The first of the two interpretation options mentioned in the <br>
> background information is the only valid interpretation <br>
> when we assume, that layered implementation of parts of <br>
> the MPI-2 standard should be possible.<br>
> This was a goal of the MPI-2 Forum and the MPI-2.0 specification.<br>
> ___________________________________<br>
> <br>
> Comment:<br>
> In the discussion (see the mails from 1999) <br>
> one can clearly see, that an implementation of option 2 (done by IBM) <br>
> cannot coexist with a layered implementation of MPI parallel<br>
> file I/O, because MPI parallel file I/O routine need a different <br>
> implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided)<br>
> need the original INF implementation.<br>
> Two different INFO implementations cannot coexist in the same MPI library.<br>
> <br>
> We could see the ouutcome of such problems with MPI_Wait & co.<br>
> as long as a generalized request concept was not available.<br>
> ROMIO had to define non-standard MPIO_Wait & co. routines.<br>
> And they persist for a long time!<br>
> <br>
> Without the clarification above, we have the same problem with the <br>
> INFO handling. <br>
> <br>
> Best regards<br>
> Rolf<br>
> <br>
> <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>
> </tt><tt><a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a></tt><tt><br>
</tt></body></html>