Okay, here’s another try. Please let me know if this is now correct. (Sorry for the delay ― I am at IPDPS and the wifi is not so good) Kathryn _________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA From: <Schulz>, Martin <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Monday, May 19, 2014 at 9:37 AM To: "'[email protected]'" <[email protected]>, "'<[email protected]>'" <[email protected]> Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? Re: [mpiwg-tools] Ticket #383 -- Final text? Either option is fine with me - I can see the argument either way Martin Sent with Good (www.good.com) -----Original Message----- From: Jeff Squyres (jsquyres) [[email protected]] Sent: Monday, May 19, 2014 09:25 AM Pacific Standard Time To: Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? Good point. I like INOUT, but wont' fight too hard if people want to drop it. On May 19, 2014, at 12:08 PM, "Schulz, Martin" <[email protected]> wrote:
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 [[email protected]] Sent: Monday, May 19, 2014 08:31 AM Pacific Standard Time To: Bronis R. de Supinski; [email protected] Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?
Jeff,
Is this what you want for the text, attached?
Kathryn _________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <[email protected]> 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 <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools