[PATCH] D24159: Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread context.
Eric Fiselier via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 1 14:31:56 PDT 2016
EricWF created this revision.
EricWF added reviewers: mclow.lists, bcraig.
EricWF added a subscriber: cfe-commits.
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.
Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:
>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.
However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".
https://reviews.llvm.org/D24159
Files:
include/thread
src/condition_variable.cpp
test/std/thread/thread.condition/PR30202_notify_from_pthread_created_thread.pass.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D24159.70067.patch
Type: text/x-patch
Size: 4724 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160901/7c24dcd8/attachment.bin>
More information about the cfe-commits
mailing list