What about providing garbage collection for both POSIX and MPI threads? This problem hints at several underlying layers of "programming faults".
-----Original Message----- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain Sent: Wednesday, July 16, 2014 8:59 AM To: Open MPI Developers Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal 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 _______________________________________________ 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/15170.php ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7863 - Release Date: 07/16/14
