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

[Junchao Zhang]

I just browsed this ticket.  I remember the standard allows the same pvar
name for pvars of different classes.
I'm not sure if this ticket is still fine on that.

--Junchao Zhang


On Mon, May 19, 2014 at 10:38 AM, Jeff Squyres (jsquyres) <
jsquyres at cisco.com> wrote:

> 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/
>
> _______________________________________________
> 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/4b59052f/attachment-0001.html>