# [mpiwg-p2p] Get/Set Info Update

Jim Dinan james.dinan at gmail.com
Mon Jan 30 09:54:07 CST 2017

Hi All,

I would like to use today's meeting (coming up in 1 hour at 11am CT) to
review the new text that I sent out earlier.

Connection info is on the wiki: https://github.com/mpiwg-p2p/p2p-issues/wiki

~Jim.

On Mon, Jan 23, 2017 at 5:22 PM, Jim Dinan <james.dinan at gmail.com> wrote:

> Hi All,
>
> I made a first attempt at updating the get/set info text with the feedback
> from the December meeting.  For starters, I'm working with just the
> communicator get/set info text, so please ignore RMA and I/O for now.  For
> the previous draft of the proposal, please refer to the PDF posted under
> "references" on the issue page (https://github.com/mpi-forum/
> mpi-issues/issues/63) or the existing PR.
>
> I pushed the changes to a work-in-progress branch, in case anyone would
> like to see the history (https://github.com/mpiwg-p2p/
> mpi-standard/tree/wip/get-info).  You can also compare with the main
> spec: https://github.com/mpi-forum/mpi-standard/compare/
> mpi-3.x...mpiwg-p2p:wip/get-info?expand=1
>
> Here's the to-do list I captured from the last meeting:
>
>  1. Remove info key deletion by omission in calls to set_info (breaks
> existing semantic)
>  2. Allow get_info to return keys not set by the user (e.g. "filename"
> info key)
>  3. Should get_info return all info keys supported by the implementation?
>
> I took a whack at #1 and #2.  I'm still thinking about how to handle info
> keys that don't have good defaults (e.g. "filename") and whether #3 is a
> good idea.  Anyway, without further ado, here is the updated text:
>
> MPI_COMM_SET_INFO:
>
> \mpifunc{MPI\_COMM\_SET\_INFO} updates the hints of the
> communicator associated with
> \mpiarg{comm} using the hints provided in \mpiarg{info}.
>
> \mpifunc{MPI\_COMM\_SET\_INFO} is a collective
>
> routine. The info object may be different on each process, but any
>
> info entries that an implementation requires to be the same on all
>
> processes must appear with the same value in each process's info
> object.
>
> \begin{users}
> Some info items that an implementation can use when it creates a
>
> communicator cannot easily be changed once the communicator has been
> created. Thus, an implementation may ignore hints issued in this call
> that it would have accepted in a creation call.
>
> %
> An implementation may also be unable to update certain info hints once
> set.
> %
> \mpifunc{MPI\_COMM\_GET\_INFO} can be used to determine whether updates
> to existing info hints were ignored by the implementation.
>
> \end{users}
>
> MPI_COMM_GET_INFO:
>
> \mpifunc{MPI\_COMM\_GET\_INFO} returns a new info object containing
> the hints of the communicator associated with \mpiarg{comm}.
> %
> The current setting of all hints related to this communicator is returned
> in
> \mpiarg{info\_used}, including any user-supplied hints that were not
> ignored
> by the \MPI/ implementation.
> %
> If no such hints
> exist, a handle to a newly created info object is returned that
> contains no key/value pair. The user is responsible for freeing
> \mpiarg{info\_used} via \mpifunc{MPI\_INFO\_FREE}.
>
> \begin{users}
> The info object returned in \mpiarg{info\_used} will contain all hints
> currently active for this communicator. This set of hints may differ
> from the set of hints specified during communicator creation or in a call
> to \mpifunc{MPI\_COMM\_SET\_INFO}, as some hints and info updates
> specified
> by the user may be ignored by \MPI/ implementation.  Additional info hints
> that are set by \MPI/ implementation may also be present.
> \end{users}
>
> Please send feedback!
>  ~Jim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20170130/03668f23/attachment-0001.html>