That sounds right. I don't know if this would still be required with the destructor, but we could also:
* add an OBJ_CLASS_DEREGISTER and require that all instantiations be matched by deregister at close of the framework/component that instanced it. Of course, that requires that we protect the class system against someone releasing/deconstructing an object after the class was deregistered since we don't know who might be using that class outside of where it was created. * ensure each framework/component "deregisters" every declared MCA param when finalizing/closing * ensure every framework close gets called, and that every framework properly closes all its components. We especially need to ensure that components that were opened but not selected get closed! I'm willing to do my part of the above (I know the third one needs to be done in ORTE) Ralph On Jul 16, 2014, at 7:26 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > A number of issues have been raised as part of this discussion. Here is > what I have seen so far: > > - contructor/destructor order not garaunteed: From an opal perspective > this should not be a problem. Most components are unloaded by > opal_finalize () not opal_finalize_util (). So opal components > opal should already be finalized by the time the destructor is called > (or we can finalize them in the destructor if necessary). > > - portability: All the compilers most of us care about: gcc, intel, > clang. The exceptions appear to be xlc and pgi. For these compilers > we can fall back on Ralph's solution and just leak if > MPI_Finalize () is not called after MPI_T_Finalize (). Attached is an > implementation that does that (needs some adjustment). > > > -Nathan > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15166.php
