[mpiwg-tools] Open MPI pvar scheme

[Junchao Zhang]

After reading mails in this thread, it seems we just want to get names of
elements in a pvar, right?
So, why do not provide this functionality directly.
  // Return true or false in has_subnames.
  MPI_T_pvar_has_subnames(session, handle, int has_subnames);
  // If has_subnames, use this function to get their names
  MPI_T_pvar_get_subnames(session, handle, char * subnames[], int lens[]);
// Very like the newly proposed MPI_T_pvar_read_str()

--Junchao Zhang

On Tue, Nov 12, 2013 at 4:09 PM, Schulz, Martin <schulzm at llnl.gov> wrote:

>
> On Nov 12, 2013, at 12:51 PM, "Jeff Squyres (jsquyres)" <
> jsquyres at cisco.com>
>  wrote:
>
> > On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <schulzm at llnl.gov> wrote:
> >
> >>>> I think it would be better to programmatically express such
> relationships -- i.e., something new for MPI-4.
> >>
> >> I agree with that, but I see it more as an MPI 3.1 feature. Is it
> really a major concept?
> >
> > I thought it was "more" than a minor/bug fix concept... and therefore
> should wait until 4.
>
> We need to finally discuss and decide that (as the forum) - this will
> definitely be on the agenda in December.
>
> >>> Er... I don't understand.  Why can't the enum strings change?  I think
> they can change at any time.
> >>
> >> So that's a good question - I was assuming (at least that's how I
> always thought about it) that the same rules as for variables and all their
> metadata apply here - once read, a description cannot change and an
> enumeration type can worst thing grow. It is correct, though, that we
> didn't specify that explicitly - perhaps we need to do that. The only text
> that comes close is "The second datatype class, enumeration datatypes,
> describes variables with a fixed set of discrete values.".
> >
> > Mmm.  Yes.  This *implies* that they don't change, but one could argue
> different meanings of "fixed set".
>
> I know, this is ambiguous.
>
> >
> >> Having strings change underneath would be a real problem for the string
> interface, since it makes the assumption that you can run queries against a
> string more than once and get the same string.
> >
> > It sounds like you are introducing a new requirement, then: you want
> non-mutable strings, but the ability to have things change over time (e.g.,
> new NICs added or old NICs dropped).
>
> Well, I think we have two separate issues here:
> - Should strings be allowed to change? In particular, should we allow
> enumerations to change on the fly? I think the answer to this should be no,
> since this would create race conditions and it would prevent tools from
> caching any data (that's why we did it for the variable metadata and for
> the types it seems even more relevant)
> - Do we need a mechanism to describe changing variable arrays? This is
> more a requirement question - how is this in your case? Will you support
> changing number of NICs and how are you planning on doing that?
>
> >
> >>> I think what you might be saying is that the *count* on a handle can't
> change -- right?  I.e., MPI_T currently has no way of saying, "There were N
> values when you called pvar_handle_alloc() for this pvar, but now this pvar
> has M values."
> >>
> >> Yes, but the count can change when you get a new handle.
> >
> > That would be fairly hellish for an implementation: session/handle X has
> N values, but simultaneously, session/handle Y of the same pvar -- which
> just happened to be created after session/handle X -- has M values.
> >
> > Meaning: the implementation has to track two entirely different
> views/counts of the same pvar.
>
> Well, wouldn't that be up to the implementation? If it doesn't make sense
> for a particular case, then an MPI can always return the same count. I
> agree, if an MPI does do it that way, it won't be easy.
>
> >
> >> Yes, that's what I meant with "doesn't have to be at the moment" - any
> variable that has the potential to have a count that is not 1 is affected.
> >
> > ...which is *any* variable, right?
>
> Yes - what I meant was that if there is a variable that a particular MPI
> implementation always decides to return 1 for, then you will probably never
> need a matching enumeration variable. However, just because it returns 1
> once, it doesn't mean that it is guaranteed that it will stay that way for
> the rest of the run or during the next run. Hence, matching enumeration
> variables make sense even for variables that have a count of 1.
>
> Martin
>
>
> >
> > --
> > Jeff Squyres
> > jsquyres at cisco.com
> > For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> >
>
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
>
> _______________________________________________
> 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/20131113/d44f11e2/attachment-0001.html>