Fix a bad bug in folly::ThreadLocal (incorrect using of pthread)
authorAlexander Shaposhnikov <alexshap@fb.com>
Tue, 4 Aug 2015 06:24:18 +0000 (23:24 -0700)
committerfacebook-github-bot-4 <folly-bot@fb.com>
Tue, 4 Aug 2015 07:22:17 +0000 (00:22 -0700)
commit0347a79f57ee6e1179c0482adacf3a7e6ff890ff
tree2876595a0e4299eed914bb4dfc65630f723caddb
parentcbaaa2db9b6b5e4873af7ce67d2a1631c012f08e
Fix a bad bug in folly::ThreadLocal (incorrect using of pthread)

Summary: Fix incorrect using of pthread in folly::ThreadLocal.

The root of the trouble (see man pthread_key_create):
"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."

At thread exit we need to recover the thread-specific threadEntry
otherwise the subsequent calls of getThreadEntry may recreate it
(what actually DOES  happen in the test ThreadLocalPtr.CreateOnThreadExit)
and the newly created threadEntry will "leak". It will live longer than the corresponding
thread violating the internal invariant of StaticMeta and also it will break
the code of the method onThreadExit. In particular this bug causes the failure
of the test ThreadLocalPtr.CreateOnThreadExit on OSX.

Reviewed By: @lbrandy

Differential Revision: D2304950
folly/detail/ThreadLocalDetail.h