Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*

APIs, to avoid a crash with the pthread implementation in RHEL 5.  Patch
by Charles-François Natali.

Include/pystate.h

@@ -132,6 +132,7 @@ PyAPI_FUNC(void) PyThreadState_Clear(PyThreadState *);
 PyAPI_FUNC(void) PyThreadState_Delete(PyThreadState *);
 #ifdef WITH_THREAD
 PyAPI_FUNC(void) PyThreadState_DeleteCurrent(void);
+PyAPI_FUNC(void) _PyGILState_Reinit(void);
 #endif
 
 PyAPI_FUNC(PyThreadState *) PyThreadState_Get(void);

Misc/NEWS

@@ -10,6 +10,10 @@ What's New in Python 3.3 Alpha 1?
 Core and Builtins
 -----------------
 
+- Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_*
+  APIs, to avoid a crash with the pthread implementation in RHEL 5.  Patch
+  by Charles-François Natali.
+
 - Issue #10914: Initialize correctly the filesystem codec when creating a new
   subinterpreter to fix a bootstrap issue with codecs implemented in Python, as
   the ISO-8859-15 codec.

Modules/signalmodule.c

@@ -991,6 +991,7 @@ void
 PyOS_AfterFork(void)
 {
 #ifdef WITH_THREAD
+    _PyGILState_Reinit();
     PyEval_ReInitThreads();
     main_thread = PyThread_get_thread_ident();
     main_pid = getpid();

Python/pystate.c

@@ -586,6 +586,23 @@ _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