I discussed this over IM with Nathan to try and get a better understanding of the options. Basically, we have two approaches available to us:
1. my solution resolves the segv problem and eliminates leaks so long as the user calls MPI_Init/Finalize after calling the MPI_T init/finalize functions. This method will still leak memory if the user doesn't use MPI after calling the MPI_T functions, but does mean that all memory used by MPI will be released upon MPI_Finalize. So if the user program continues beyond MPI, they won't be carrying the MPI memory footprint with them. This continues our current behavior. 2. the destructor method, which release the MPI memory footprint upon final program termination instead of at MPI_Finalize. This also solves the segv and leak problems, and ensures that someone calling only the MPI_T init/finalize functions will be valgrind-clean, but means that a user program that runs beyond MPI will carry the MPI memory footprint with them. This is a change in our current behavior. I'm not sure which approach is best, but I think this captures the heart of the decision. On Jul 16, 2014, at 7:36 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > On Wed, Jul 16, 2014 at 08:26:44AM -0600, Nathan Hjelm 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). > > Correction. xlc does support the destructor function attribute. The odd > one out is PGI. > > -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/15168.php
