Issue #19787: PyThread_set_key_value() now always set the value

In Python 3.3, PyThread_set_key_value() did nothing if the key already exists
(if the current value is a non-NULL pointer).

When _PyGILState_NoteThreadState() is called twice on the same thread with a
different Python thread state, it still keeps the old Python thread state to
keep the old behaviour. Replacing the Python thread state with the new state
introduces new bugs: see issues #10915 and #15751.

1 files changed, 9 insertions, 9 deletions

diff --git a/Python/pystate.c b/Python/pystate.c
index a56e308..19fceb7 100644
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -723,18 +723,18 @@ _PyGILState_NoteThreadState(PyThreadState* tstate)
 
        The only situation where you can legitimately have more than one
        thread state for an OS level thread is when there are multiple
-       interpreters, when:
+       interpreters.
 
-           a) You shouldn't really be using the PyGILState_ APIs anyway,
-          and:
+       You shouldn't really be using the PyGILState_ APIs anyway (see issues
+       #10915 and #15751).
 
-           b) The slightly odd way PyThread_set_key_value works (see
-          comments by its implementation) means that the first thread
-          state created for that given OS level thread will "win",
-          which seems reasonable behaviour.
+       The first thread state created for that given OS level thread will
+       "win", which seems reasonable behaviour.
     */
-    if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
-        Py_FatalError("Couldn't create autoTLSkey mapping");
+    if (PyThread_get_key_value(autoTLSkey) == NULL) {
+        if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
+            Py_FatalError("Couldn't create autoTLSkey mapping");
+    }
 
     /* PyGILState_Release must not try to delete this thread state. */
     tstate->gilstate_counter = 1;