On Nov 11, 2013, at 7:03 PM, "Schulz, Martin" <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/