tavianator added a comment. In http://reviews.llvm.org/D21803#469988, @bcraig wrote:
> You should look at __thread_specific_ptr in libcxx's <thread>. It does a lot > of these things in order to satisfy the requirements of > notify_all_at_thread_exit, set_value_at_thread_exit, and > make_ready_at_thread_exit. Had a look at it. One thing that stands out is that notify_all_at_thread_exit() and friends are supposed to be invoked *after* thread_local destructors. But the order that pthread_key destructors run in is unspecified. This could be worked around by waiting for the second iteration through pthread_key destructors before triggering ~__thread_struct_imp(). It looks like libstdc++ has a similar bug if ..._impl() isn't available. > @rmaprath has been doing some work to make the threading runtime library > swappable. I don't recall if his work extended to libcxxabi or not, but I'll > page him anyway. <__threading_support>? Seems to be libc++-specific. There's a few other raw uses of pthreads in libc++abi. > This implementation of __cxa_thread_atexit doesn't interact nicely with > shared libraries. The following sequence of events causes unloaded code to > get invoked. > > - Create thread 42 > - Load library foo from thread 42 > - Call a function with a thread_local object with a dtor. > - Unload library foo. > - Join thread 42 > > glibc does some extra work during __cxa_thread_atexit_impl to bump the > reference count of the shared library so that the user's "unload" doesn't > actually unload the library. Yep. This is about as good as libc++abi can do on its own though. Note that libstdc++ has similar limitations if ..._impl() isn't available. http://reviews.llvm.org/D21803 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
