Re: MPI_File_get_comm

Bill Nitzberg (nitzberg@nas.nasa.gov)
Wed, 15 Jan 1997 15:31:51 -0800

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Rajeev Thakur: "levels of interoperability"
Previous message: Nick Maclaren: "Re: I/O Chapter Updates & Jan Meeting Agenda"
Maybe in reply to: Linda Stanberry: "MPI_File_get_comm"

In message <199701092011.MAA25816@anduin.ocf.llnl.gov> Linda Stanberry writes
> I am wondering what is the intended use of the returned communicator from
> a call to MPI_File_get_comm? Since the semantics of this call currently
> specifies that a duplicate of the communicator is returned, the returned
> communicator will not compare equal (MPI_IDENT) to the communicator used to
> open the file (it will have a different context), and hence will not be
> valid for messages to/from the communicator associated with the file.

> [...]

The motivation behind MPI_File_get_comm was two-fold: to support
third party libraries and for completeness. A third party library
may need to retrieve the set of processes which opened a file, but
only have the file handle; getting the communicator is a convenient
mechanism for this. As far as completeness goes---everything else
has an get routine...

> I am also wondering why MPI_File_get_comm is a collective operation.

Creating a dup of a communicator is a collective operation.

> I look forward to being illuminated about these mysteries!
>
> Linda Stanberry
> lstanberry@llnl.gov

- bill

Next message: Rajeev Thakur: "levels of interoperability"
Previous message: Nick Maclaren: "Re: I/O Chapter Updates & Jan Meeting Agenda"
Maybe in reply to: Linda Stanberry: "MPI_File_get_comm"