[mpiwg-tools] Open MPI pvar scheme

[Jeff Squyres (jsquyres)]

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.

>> 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".

> 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).

>> 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.

> 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?

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/