From: "Rolf Rabenseifner" Date: February 1, 2008 11:14:20 AM CST To: Richard Treumann ,rabenseifner@XXXXXXX, Cc: "Bill Gropp" , "Rajeev Thakur" , Rob Ross Subject: Re: Fw: [mpi-21] Ballot 4 - MPI_File_get_info Dick, I expect that Bill had put the question on the errata page and I do not know the historical reason. As MPI 2.1 chair, I try to take all unclear items and to bring them into a clear state. I took your input mainly as the information that this clarification is only needed for implementations, that do not use any default infos on file handles. Therefore, this clarification may not have any impact on current implementations. A portable user appplication should be aware, that the MPI standard does not guarantee default hints on file handles. And therefore the application programmer should know where he/she must make which if-statement to have not a broken application code. Do we know, what a cheap and light MPI implementation may offer on a beautiful xxx-flop-platform in 7 years? Therefore this clarification is mainly for consistency and portability. Okay? Best regards Rolf On Fri, 1 Feb 2008 09:23:09 -0500 Richard Treumann wrote:> > > Is this still topic still open? I sent this note suggesting the > issue is > moot and have not seen any response. If no response means the > question has > been removed from consideration, that is fine. If not, what next. > I was > not able to find discussion history older than Rolf's note and Bronis' > reply so I do not know where the original concern came from. > > Thanks > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > ----- Forwarded by Richard Treumann/Poughkeepsie/IBM on 02/01/2008 > 09:08 AM > ----- > > Richard > Treumann/Poughkee > psie/ > IBM@IBMUS To > Sent by: "Mailing list for discussion > of MPI > mpi-21-bounces@cs 2.1" > .uiuc.edu > cc > > > Subject > 01/31/2008 09:25 Re: [mpi-21] Ballot 4 - > AM MPI_File_get_info > > > Please respond to > "Mailing list for > discussion of MPI > 2.1" > du> > > > > > > > I think this proposal is moot unless it is intended as a loophole > to allow > an implementation to provide a zero-functionality version of the INFO > bindings. The "filename" hint is always present on an MPI_File so > there > should never be a empty MPI_FILE_GET_INFO return. > > Dick > hh > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-21-bounces@XXXXXXXXXXX wrote on 01/31/2008 08:01:20 AM: > >> This is a proposal for MPI 2.1, Ballot 4. >> >> I'm asking especially the implementors to check, whether >> this interpretation is implemented in their MPI implementations, >> or does not contradict to the existing implementation. >> >> This is a follow up to: >> MPI_File_get_info >> in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion not yet existing >> ___________________________________ >> >> Proposal: >> MPI-2.0 Sect. 9.2.8, File Info, page 219, lines 11-13 read: >> >> MPI_FILE_GET_INFO returns a new info object containing the hints >> of the file associated with fh. The current setting of all hints >> actually used by the system related to this open file is returned >> in info_used. >> The user is responsible for freeing info_used via MPI_INFO_FREE. >> >> but should read (" or an abort(errorcode)" removed): >> >> MPI_FILE_GET_INFO returns a new info object containing the hints >> of the file associated with fh. The current setting of all hints >> actually used by the system related to this open file is returned >> in info_used. >> If there does not exist such a hint, MPI_INFO_NULL is returned. >> The user is responsible for freeing info_used via MPI_INFO_FREE >> if info_used is not MPI_INFO_NULL. >> ___________________________________ >> Rationale for this clarification: >> This text was missing. It was not clear, whether a MPI_Info handle >> would be returned that would return nkeys=0 from >> MPI_INFO_GET_NKEYS. >> From user's point of view, this behavior might have been expected >> without this clarification. >> ___________________________________ >> >> As far as I understand, ROMIO is using for all filesystems some >> default >> hints and therefore "no-hints" is never returned. >> MPI_File_set_view and MPI_File_set_info are only modifying values >> but do not remove keys. >> Therefore, the info handle cannot become empty. >> >> 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 > _______________________________________________ > mpi-21 mailing list > mpi-21@XXXXXXXXXXX > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 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)