On Aug 16, 2007, at 1:13 PM, Tim Prins wrote:
So you're both right. :-) But Tim's falling back on an older (and
unfortunately bad) precedent. It would be nice to not extend that
bad precedent, IMHO...
I really don't care where the constants are defined, but they do
need to
be unique. I think it is easiest if all the constants are stored in
one
file, but if someone else wants to chop them up, that's fine with
me. We
would just have to be more careful when adding new constants to check
both files.
Ya, IIRC, this is a definite problem that we had: it's at the core of
the "component" abstraction (a component should be wholly self-
contained and not have any component-specific definitions outside of
itself), but these tags are a central resource that need to be
allocated in a distributed fashion.
That's why I think it was decided to simply leave them as they were,
and/or use the (DYNAMIC-x) form. I don't have any better suggestion;
I'm just providing rationale for the reason it was the way it was...
True. We will need a robust tag reservation system, though, to
guarantee that every process gets the same tag values (e.g., if udapl
is available on some nodes but not others, will that cause openib to
have different values on different nodes? And so on).
Not really. All that is needed is a list of constants (similar to the
one in rml_types.h).
I was assuming a dynamic/run-time tag assignment (which is obviously
problematic for the reason I cited, and others). But static is also
problematic for the breaking-abstraction reasons. Stalemate.
If a rsl component doesn't like the particular
constant tag values, they can do whatever they want in their
implementation, as long as a messages sent on a tag is received on the
same tag.
Sure.
--
Jeff Squyres
Cisco Systems
