Let me offer an alternative, if it would help. What if we:
1. remove all calls to opal_init/finalize from orte_init/finalize. ORTE will
only init and finalize it's own layer
2. rename opal_init to opal_init_frameworks, and ditto for opal_finalize. This
makes it clear what those functions actually do. Also, remove the call to
opal_finalize_util that is currently in opal_finalize so all that the renamed
function does is finalize the non-utils.
Now we get George's desired symmetry in a way I can understand. Each function
does only what it claims. As the MPI layer is the highest in the hierarchy, it
has the responsibility of initting opal and then orte, and finalizing orte and
then opal. so if someone really wants to use opal after finalizing orte, knock
yourselves out. It is easy enough to have the tools do the same.
Anyone using orte without first initting opal will quickly discover their
mistake! But that's not a big deal, IMO.
Is that more acceptable?
On Jul 11, 2011, at 8:01 AM, Jeff Squyres wrote:
> 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/
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
