On Friday 17 August 2007 13:58, Jeff Squyres wrote: > 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.
What's about this. Every component choose its own tag independent from the others. Before a component can use the tag it must register with its full name and the tag at a small (process intern) database. If 2 components try to register the same tag we emit a warning, terminate the processes, ... . If 2 components (CompA and CompB) want to register the same tag and we assume that process A loads _only_ CompA while processes B loads _only_ CompB than both components will be loaded without any error. I assume that it's rather unusual that CompA send a message to process B as there is no counter component. But there is still some probability. For more safety (and of course less performance) we could : - add a parameter that cause this tag database to sync. across all processes. - add a parameter that turns a check for every send/receive, if the specified tag has been used or not Just my 0.02 $ Sven > > 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 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
