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 <[email protected]> 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.