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 <phhargr...@lbl.gov> 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.m...@gmail.com> 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 <phhargr...@lbl.gov> wrote: > > On Tue, Jul 15, 2014 at 12:49 PM, Pritchard, Howard r <howa...@lanl.gov> > 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 phhargr...@lbl.gov > 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 > 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/15153.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/15155.php > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > 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 > 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/15156.php
