I'm unsure where Intel's compilers sit on that list. When you say it works except for reinit, are you saying that the only issue here is that MPI_T_Finalize is calling opal_finalize_util solely because of the valgrind cleanup? And if it didn't do that, we would leak but would otherwise be just fine?
Just checking my understanding. Looking at the code, that would certainly appear to be true due to the reference counter in there, which would prevent us from eventually cleaning up because the counter wouldn't reach zero. However, couldn't we resolve that by (a) having MPI_T_Init set a global flag indicating it was called, and then (b) in opal_finalize, check the flag and add another call to opal_finalize_util if the flag is set? Seems like all we really need to do is ensure that the init/finalize calls match, and that is far easier to ensure than doing the rest of this stuff. On Jul 15, 2014, at 5:48 PM, George Bosilca <bosi...@icl.utk.edu> wrote: > Enforcing the portability of this sounds like a huge [almost impossible] > mess, without a clean portable solution (more about this below). However, few > things should be considered: > - Except for reinit, Open MPI works without it! If we provide such a > capability it will be more a convenience capability to keep valgrind happy, > than a necessity > - in case the constructor/destructor functionality is available we explicitly > control the ordering in which the shared libraries are opened/closed as we > control the dl_open/dl_close for most of the shared libraries. > > George. > > PS: Other cases about shared libraries constructor/destructor. > > The easy ones. > Mac OS X: > https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html > > Solaris: http://docs.oracle.com/cd/E18659_01/html/821-1383/bkamq.html > > And the others > > PGI: > http://www.pgroup.com/userforum/viewtopic.php?t=697&sid=4efce7bfb4e914e42f48f219fc7e6a7e > > XLC: beg for forgiveness (there is a -binitifini function but it must be > specified at link time) > > > > > > > On Tue, Jul 15, 2014 at 8: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 > > _______________________________________________ > 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/15158.php
