[mpiwg-tools] Ticket #383 -- Final text?

Jeff Squyres (jsquyres) jsquyres at cisco.com
Mon May 19 10:00:40 CDT 2014


On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm at llnl.gov> wrote:

> Hi Kathryn, all,
> 
> A few comments:
> - "Adhere to the same definition from the MPI implementation.” - not sure
> what we meant with this anymore. Perhaps we should just drop this part.

What I meant by that is that each MPI implementation will create a definition for each cvar/pvar/etc.  The implementation must adhere to that same definition in all connected processes.  I.e., it can't change the definition of exactly what that variable is in different processes (e.g., bytes_in = bytes received from TCP in one process, but bytes received across shared memory in another process).

> - "OUT index values” is not correct, since index values are IN parameters
> to the get_info calls. Perhaps just drop OUT?

Good catch; missed that.  Yes, this whole clause can go.

> - The mandate of equal OUT/INPUT values is also not quite right - for the
> strings, it’s OK to return substrings of the size argument is too small. I
> know that’s a technicality, but I am not sure if this causes problems
> later down the road.

Mmm.  Good point.  So the current text is:

 * Return the same INOUT and OUT values from the relevant MPI_T_*_GET_INFO function.

(I took the liberty of dropping the index value clause)

I notice that we actually return 3 kinds of things from GET_INFO functions: integers/enums, strings, and MPI handles (i.e., MPI_Datatype).  So how about this:

 * Return the same INOUT and OUT integer and enum values from the relevant MPI_T_*_GET_INFO function.  
 * If sufficiently long enough string length IN parameters are supplied, return the same string OUT parameters from the relevant MPI_T_*_GET_INFO function.
 * Return a handle to an equivalent MPI object from the relevant MPI_T_*_GET_INFO function.



-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/



More information about the mpiwg-tools mailing list