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

[Schulz, Martin]

Looks mostly good to me, but length arguments are INOUT, so that may be confusing - perhaps just drop the IN?

Martin



Sent with Good (www.good.com)


-----Original Message-----
From: Kathryn Mohror [kathryn at llnl.gov<mailto:kathryn at llnl.gov>]
Sent: Monday, May 19, 2014 08:31 AM Pacific Standard Time
To: Bronis R. de Supinski; mpiwg-tools at lists.mpi-forum.org
Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140519/5f81a47a/attachment-0001.html>