[mpiwg-tools] proposed text
schulzm at llnl.gov
Thu Nov 13 11:26:50 CST 2014
Comments inline below.
Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
On 11/13/14, 9:06 AM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:
>Here's what I understand from Martin+me at the end of the call:
>- name and desc are OUT strings, for both control and perf vars. So we
>need to have this whole mess apply to all 4 cases.
There are actually 6 cases - two more for the categories.
>- we keep the idea of separating the two concepts:
> 1. the (conceptual) internal value for the string, which will be
>identical across connected processes
> 2. copying it to an output buffer, where it may be truncated
>- so up in 14.3.3, have a definition for "<foo> strings" (someone come up
>with a better name than "<foo>"):
> - an MPI implementation behaves if the string is identical across all
Not sure what you mean with behaves - I think you mean we define what
identical means in 14.3.3 (which is trivial) and then say what this means
when copied into output buffer.
If two MPI_T strings are identical, the corresponding routine returning
the string returns, for any length parameter passed into the routine, an
identical content in the string buffer up to the null terminating
> - when this string is copied to an output buffer, it may be truncated
>(e.g., if the user specifies an output buffer length that is too small).
>- Then in the four cases (name/desc for control/perf vars), say that they
>are <foo> strings. For example, "desc is a <foo> string (see section
Yes, this should go into the actual parameter/argument specification of
and then we just say if the name is identical, the following OUT
parameters, , and the description has to be identical as well
>Something along these lines...
>jsquyres at cisco.com
>For corporate legal information go to:
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
More information about the mpiwg-tools