From 1f3ff7bc3f7cfd4e823e49dc193ab7fecb767c43 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Charles-Fran=C3=A7ois=20Natali?= Date: Wed, 12 Oct 2011 21:07:54 +0200 Subject: Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native TLS implementations, and fails with the ad-hoc TLS implementation when a thread doesn't have an auto thread state (e.g. a thread created outside of Python calling into a subinterpreter). --- Python/pystate.c | 17 ----------------- 1 file changed, 17 deletions(-) (limited to 'Python') diff --git a/Python/pystate.c b/Python/pystate.c index 3eefa36a26..ddb7d42589 100644 --- a/Python/pystate.c +++ b/Python/pystate.c @@ -537,23 +537,6 @@ _PyGILState_Fini(void) autoInterpreterState = NULL; } -/* Reset the TLS key - called by PyOS_AfterFork. - * This should not be necessary, but some - buggy - pthread implementations - * don't flush TLS on fork, see issue #10517. - */ -void -_PyGILState_Reinit(void) -{ - PyThreadState *tstate = PyGILState_GetThisThreadState(); - PyThread_delete_key(autoTLSkey); - if ((autoTLSkey = PyThread_create_key()) == -1) - Py_FatalError("Could not allocate TLS entry"); - - /* re-associate the current thread state with the new key */ - if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0) - Py_FatalError("Couldn't create autoTLSkey mapping"); -} - /* When a thread state is created for a thread by some mechanism other than PyGILState_Ensure, it's important that the GILState machinery knows about it so it doesn't try to create another thread state for the thread (this is -- cgit v1.2.1