On Jul 11, 2011, at 7:28 AM, George Bosilca wrote:
>> How about a compromise?
>
> Based on the english dictionary a compromise is an agreement or a settlement
> of a dispute that is reached by each side making concessions. This is not a
> compromise. This is exactly what Ralph did plus name changes. Therefore, this
> is a single sided settlement.
Actually, it gives you what you wanted, too (i.e., the ability to separately
init/finalize OPAL util vs. the rest of OPAL).
Hence, it's a compromise.
>> - Take what is (essentially) in opal_init() today and rename it to be
>> opal_init_frameworks() -- because it's (mostly) initializing the OPAL MCA
>> frameworks.
>>
>> - Take what is (essentially) in opal_finalize() today and rename it to be
>> opal_finalize_frameworks() -- because it's (mostly) finalizing the OPAL MCA
>> frameworks. Remove the call to opal_finalize_util() from this function.
>>
>> - Remove all use of counters; calling opal_init*() will initialize (unless
>> it has already been initialized), and calling opal_finalize*() will finalize
>> (unless it has already been finalized).
>>
>> - Create a new opal_init() function that is a wrapper around
>> opal_init_util() and opal_init_frameworks(). Create a new opal_finalize()
>> function that is a wrapper around opal_finalize_util() and
>> opal_finalize_frameworks().
>>
>> - orte_finalize() will call opal_finalize() -- i.e., it will unconditionally
>> shut down all of OPAL. This will remove the need for opal_finalize_util()
>> in the MPI layer.
>>
>> This seems to give all desired behaviors:
>>
>> - All <foo>_finalize() functions will be unconditional. The Law of Least
>> Surprise is preserved.
>>
>> - There are paths for split init and split finalize and combined init and
>> combined finalize. They can even be combined (e.g., split init and combined
>> finalize -- which will be a common case, actually).
>
> Least surprise you say? How surprise one will be once he/she realize that
> orte_finalize teared down all OPAL. At least, do not forget to add one of
> those nice comments about the fact that one have to initialize the utils, but
> don't have to finalize them, ORTE will graciously do it for you.
To clarify: you can *choose* to separately initialize the OPAL utilities if you
want/need to.
Otherwise, the lower layer -- ORTE -- will both initialize and finalize OPAL
for you. Isn't that what lower layers are supposed to do?
OPAL has a weird "side entrance" because we need to use some of OPAL (MCA
params) before the rest of the system. *That's* the weird part. We actually
somewhat violate abstraction barriers there, IMHO (but I don't know any way
around that).
> You want to change names, OK go for it. At the point where the code is today,
> I don't think it really matters anymore. In fact why do we need a boolean in
> the code Ralph put inside? If the opal_finalize is supposed to clean up
> everything just go ahead and remove that useless bool. And as you made the
> code easy to understand by few, put a big comment for all the others
Do you really find this confusing?
int opal_finalize(void)
{
if (!opal_initialized) {
return OPAL_SUCCESS;
}
...
FWIW, we have similar patterns elsewhere in OMPI for preventing multiple
initializations / finalizations. Are you saying that we should remove all of
those, too?
> (the ones that will try to understand why their code break after a simple
> orte_finalize).
Can you cite any codes that will break if OPAL is finalized during
orte_finalize()? I thought you said in a prior mail on this thread that no one
uses OPAL after orte_finalize() anyway -- we *might* want to in the future, but
no one does it today. Am I remembering incorrectly?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
