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: Ralph Castain (rhc_at_[hidden])
Date: 2014-07-15 20:42:38


I wonder if we aren't using a howitzer to swat a gnat. It seems to me that this is loaded with potential problems, as Paul describes, and I shudder to think of how hard this is going to be when we consider all the compiler/environment combinations we support and the range of libraries our various pieces build against.

Wouldn't it be easier for us to spend a little time on each framework and set it up to better handle init/fini/init cycles? It seems to me that this is going to be far more involved than just cleaning up class object instantiations, and indeed in some cases is going to take careful teardown of 3rd party libraries we link against.

I know that will be more work than creating some simple "destructor", but I suspect it has far more likelihood for success and a much lower degree of risk.

On Jul 15, 2014, at 5:06 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:

> The priority appears to have been added in gcc 4.3.
> You'll note it is not described in https://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Function-Attributes.html
>
> I also don't think the presence of the priority argument fixes anything...
>
> An OpenMPI code author cannot change the "priority" of a ctor or dtor in a precompiled third-party library (libpmi comes to mind). Nor can one know what value the third part chose (in order to be higher or lower than theirs). You cannot even be assured the third-party didn't set priority to INT_MIN or INT_MAX (or whatever).
>
> That text also says nothing about dl_open() and dl_close() which must be considered in Open MPI.
>
> Before assuming constructor/destructor attributes are going to save the world, wash your dog, and pick up the dry cleaning, one should probably verify some minimal level of support on non-gnu tool-chains including vendor compilers (PGI, XLC, etc) and system linkers (Darwin and Solaris).
>
> -Paul
>
>
> On Tue, Jul 15, 2014 at 4:52 PM, Joshua Ladd <jladd.mlnx_at_[hidden]> wrote:
> According to http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
>
> "constructor
> destructor
> constructor (priority)
> destructor (priority)
> The constructor attribute causes the function to be called automatically before execution enters main (). Similarly, the destructor attribute causes the function to be called automatically after main () completes or exit () is called. Functions with these attributes are useful for initializing data that is used implicitly during the execution of the program.
> You may provide an optional integer priority to control the order in which constructor and destructor functions are run. A constructor with a smaller priority number runs before a constructor with a larger priority number; the opposite relationship holds for destructors. So, if you have a constructor that allocates a resource and a destructor that deallocates the same resource, both functions typically have the same priority. The priorities for constructor and destructor functions are the same as those specified for namespace-scope C++ objects (see C++ Attributes).
>
> These attributes are not currently implemented for Objective-C."
>
>
>
>
> On Tue, Jul 15, 2014 at 5:20 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:
>
> On Tue, Jul 15, 2014 at 12:49 PM, Pritchard, Howard r <howardp_at_[hidden]> wrote:
> I don't think there's anything wrong with using ctor/dtors in shared libraries,
> but one does need to make sure that in these functions there's no assumptions
> about ordering of them wrt to other ctors/dtors.
>
> The ELF specification is clear that the order of execution of DT_INIT and DT_FINI entries is undefined.
> The .ctors and .dtors sections typically used by the GNU toolchain are, I believe, not part of any formal linker specification.
> So, I agree w/ Howard that one must take care not to assume anything about order.
>
> -Paul
>
>
> --
> Paul H. Hargrove PHHargrove_at_[hidden]
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15153.php
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15155.php
>
>
>
> --
> Paul H. Hargrove PHHargrove_at_[hidden]
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15156.php