On Mon, May 12, 2014 at 11:26 AM, Jason Merrill <[email protected]> wrote: > "The effect of dlclosing a DSO with registered thread cleanups is > undefined."
Do you mean "undefined" as in the C++ standard nasal demons sense, or just unspecified/implementation-defined? > That seems reasonable, I was just trying to allow for implementations that > don't have any way to implement that, because they can't change the dynamic > loader. That's fair, though I'd argue that's the burden of the implementation to push for appropriate mechanisms in their dependencies to implement the needed functionality. Are there platforms + toolchain combinations where this is unreasonable? E.g., a couple implementation possibilities I see (assuming appropriate platform-specific extensions are available): 1. Implement __cxa_thread_atexit directly in the dynamic linker (e.g., basically what glibc does with __cxa_thread_atexit_impl). 2. Use dladdr() to find dli_fname for dso_handle, and then use dlopen() on that filename and take advantage of the implicit refcount from using dlopen(); when the thread destructor runs, use dlclose() to release the refcount. 3. Mark any DSOs that use __cxa_thread_atexit() as DF_1_NODELETE in DT_FLAGS_1, to ensure they won't be deleted and the thread-local registration will remain valid. (Obvious consequence is this prevents the DSO's resources from being freed prior to process termination.) _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
