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 actual
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 cha
On Jul 11, 2011, at 5:37 AM, Terry Dontje wrote:
> Trying to uplevel this a bit so I can figure out which of these paths makes
> sense to me. Is the only reason we want to convert the symmetry of init and
> finalize to being asymmetric is to support an abort case? Forgive me Ralph,
> I know
Trying to uplevel this a bit so I can figure out which of these paths
makes sense to me. Is the only reason we want to convert the symmetry
of init and finalize to being asymmetric is to support an abort case?
Forgive me Ralph, I know you had posted this in one of the emails but I
wanted to
On Jul 9, 2011, at 13:43 , Jeff Squyres wrote:
> Leaving out many details, I think the arguments can be summarized as:
>
> 1. Ralph's argument is that per convention of our other 2 layers,
> "_finalize" should unconditionally finalize the layer. Just do it.
> It's also weird that opal_finali
Works for me :-)
On Jul 9, 2011, at 5:43 AM, Jeff Squyres wrote:
> Leaving out many details, I think the arguments can be summarized as:
>
> 1. Ralph's argument is that per convention of our other 2 layers,
> "_finalize" should unconditionally finalize the layer. Just do it.
> It's also weir
Leaving out many details, I think the arguments can be summarized as:
1. Ralph's argument is that per convention of our other 2 layers,
"_finalize" should unconditionally finalize the layer. Just do it. It's
also weird that opal_finalize() may actually do *nothing* (vs. finalizing at
least al
I see several main categories of leaks at the current head (I did not test
before Ralph's changes):
- a bunch of RTE leaks
--> which is think is what Ralph is trying to pare down
- OMPI pre-defined attribute leaks
--> This will take a little thinking to fix; it's complicated
- OMPI pre-defi
On Jul 8, 2011, at 16:15 , Ralph Castain wrote:
>> So we have opal_init * 1 and opal_util * 2. Clearly the opal util is not a
>> simple ON/OFF stuff. With Ralph patch the OPAL utilities will disappear as
>> soon as the OMPI layer call orte_fini. Luckily, today there is nothing
>> between the c
On Jul 8, 2011, at 7:37 AM, George Bosilca wrote:
> What memory leaks? My valgrind claims there are basically none at the MPI
> level, so I'm wondering ...
We leak nearly a megabyte, almost all of it from OPAL, when running a tool. If
you look at the commit message, this wasn't about an MPI pr
What memory leaks? My valgrind claims there are basically none at the MPI
level, so I'm wondering ...
First, let's make sure everyone understand why there are two initialization
functions in OPAL. One has to call opal_init_util before anything else
otherwise no access to utilities dealing with
11 matches
Mail list logo
