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

[Jeff Squyres (jsquyres)]

Yes.  What do others think about this?

NOTE: We have about 3.5 hours to get this right/done/sent to the mpi-forum list. (or defer to the next meeting).  I.e., T-2 weeks to the meeting is at 2pm US Central time today.

The only thing I might change is from "...return the same string OUT parameters..." to "...return the same string valued OUT parameters..."  This is the canonical issue that we don't care what the value of the (char*) pointer is; we care that the *string value* itself is what is the same.



On May 19, 2014, at 11:30 AM, Kathryn Mohror <kathryn at llnl.gov> wrote:

> Jeff, 
> 
> Is this what you want for the text, attached?
> 
> Kathryn
> _________________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
> USA
> 
> 
> 
> 
> 
> 
> On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <bronis at llnl.gov> wrote:
> 
>> 
>> "sufficiently long enough" is redundant; "sufficiently long"
>> is sufficient.
>> 
>> On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote:
>> 
>>> 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/
>>> 
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
> 
> <tools-3.pdf>_______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools


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