Repository navigation
PyThreadState_Next not thread safe #40857
Description
| BPO | 1021318 |
|---|---|
| Nosy | @pitrou, @vstinner, @devdanzin, @jd, @ericsnowcurrently, @serhiy-storchaka |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2004-09-02.16:56:47.000>
labels = ['interpreter-core', '3.9']
title = 'PyThreadState_Next not thread safe'
updated_at = <Date 2020-05-15.01:09:40.629>
user = 'https://bugs.python.org/jpe'bugs.python.org fields:
activity = <Date 2020-05-15.01:09:40.629>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-09-02.16:56:47.000>
creator = 'jpe'
dependencies = []
files = []
hgrepos = []
issue_num = 1021318
keywords = []
message_count = 14.0
messages = ['60562', '82072', '114376', '358187', '358188', '358189', '358190', '358191', '358192', '358261', '358262', '358347', '364094', '368895']
nosy_count = 7.0
nosy_names = ['jpe', 'pitrou', 'vstinner', 'ajaksu2', 'jd', 'eric.snow', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue1021318'
versions = ['Python 3.9']
Activity
jpe commentedon Sep 2, 2004
I can't convince myself that PyThreadState_Next is
thread safe even if the GIL is held because
PyGILState_Release can delete a thread state after
releasing the GIL if the gilstate_counter reaches 0.
So another thread could be deleting a thread state my
thread is referencing.
If the GIL was held when the thread state was deleted,
the I think the next function would be thread safe
because new thread states are always added to the front
of the list.
If these functions should work when the GIL is not
held, the head_mutex in pystate.c probably needs to be
exposed in some manner so code can lock it, iterate
through the threads, and then unlock it.
devdanzin commentedon Feb 14, 2009
Can someone take a look a this and either close or propose what to do?
BreamoreBoy commentedon Aug 19, 2010
No reply to msg82072.
jd commentedon Dec 10, 2019
This is actually true and it's quite easy to produce a bug that triggers a segmentation fault when iterating over a large list of threads create dynamically.
That makes PyThreadState_Next barely usable for any program that has a few threads. The head mutex needs to be locked to be able to iterate safely over the list of thread.
[-]PyThreadState_Next not thread safe?[/-][+]PyThreadState_Next not thread safe[/+]10 remaining items
vstinner commentedon Dec 10, 2019
Are you talking about this lock?
jd commentedon Dec 10, 2019
Yes, that's the one 👍
jd commentedon Dec 11, 2019
Victor, do you have an idea of how you would like this mutex to be exposed?
I see it only recently changed in Python 3.7 to be part of a structure, though this structure is not public AFAIU.
Is adding 2 new lock/unlock C functions good enough?
vstinner commentedon Dec 11, 2019
I'm not sure of what is the best approach. Currently, bpo-10915 is blocking different projects: "Make the PyGILState API compatible with multiple interpreters". We may have to fix this API first, and clarify the scope of the different locks.
ericsnowcurrently commentedon Dec 13, 2019
On Wed, Dec 11, 2019 at 7:02 AM STINNER Victor <report@bugs.python.org> wrote:
+1
vstinner commentedon Mar 13, 2020
See also bpo-35370: "Add _PyEval_SetTrace(tstate, func, arg) function".
vstinner commentedon May 15, 2020
I marked bpo-26461 as a duplicate of this issue.
a7a-dar commentedon Aug 23, 2024
ashm-dev commentedon Nov 13, 2025
Ping. Is this issue still relevant?