mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-11-01 10:45:30 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 15

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

Browse source 
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.
This commit is contained in:
Victor Stinner 2013-12-13 11:08:56 +01:00
parent cb1c4c8c22
commit 590cebe391
6 changed files with 24 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

18
Python/pystate.c
View file

@ -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;