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