Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal
From: Kenneth A. Lloyd (kenneth.lloyd_at_[hidden])
Date: 2014-07-16 12:40:50

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-bounces_at_[hidden]] 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 <hjelmn_at_[hidden]> 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
> devel_at_[hidden]
> Subscription:
> Link to this post:

devel mailing list
Link to this post:

No virus found in this message.
Checked by AVG -
Version: 2014.0.4716 / Virus Database: 3986/7863 - Release Date: 07/16/14