[cxx-abi-dev] thread_local destructors

[Lawrence Crowl]

On 9/20/12, Jason Merrill <jason at redhat.com> wrote:
> C++11 specifies that thread_local variables can have dynamic
> initialization and destruction semantics, so we need to add that to the
> existing TLS model.  As discussed in N2659 it is possible to support
> dynamic initialization in just the compiler, but for destruction we need
> a thread-local version of atexit.  This seems to call for a new runtime
> entry point __cxa_thread_atexit.
>
> The question is, do we want to try to deal with the intersection of
> threads and shared libraries?  If the user dlcloses a library with TLS
> objects that have destructors in multiple threads, trying to arrange for
> the affected threads to run the relevant destructors seems
> complex.  Are other people comfortable just saying "don't do that"?

The last paper I know about on dynamic libraries was my N2425, which says:

  The fifth feature of dynamic library support is library
  removal. This feature is also known as closing a dynamic
  library. The implications on order of destruction of
  static-duration and thread-duration variables could be severe. So,
  rather than try to define a precise meaning, we intend to provide
  advice to programmers on how to avoid the problems. In particular,

  . Programmers shall terminate all threads that reference a
    thread-duration variable defined within a load unit before
    removing that load unit from the program. In practice, this
    means that a library intended to be conditionally loadable
    should only use thread-duration variables in threads that it
    creates and then terminates before removal.

  . Programmers shall ensure that no static-duration variable is
    referenced from outside the removable load unit. In practice,
    this means that all variables in removable libraries have
    private visibility and that the library does not pass their
    addresses outside of the library.

  As code to remove a dynamic library also has low static frequency,
  so we chose to not standardize it. Programmers will need to
  specialize their code for each supported platform.

-- 
Lawrence Crowl