[mpi-21] Ballot 4 - MPI_File_get_info

Richard Treumann treumann at [hidden]
Thu Jan 31 08:25:28 CST 2008


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_at_[hidden] 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_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





* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-21/attachments/20080131/a12bc4fc/attachment.html>


More information about the Mpi-21 mailing list