[3.13] gh-137400: Fix thread-safety issues when profiling all threads (gh-137518)#137733
[3.13] gh-137400: Fix thread-safety issues when profiling all threads (gh-137518)#137733colesbury merged 6 commits intopython:3.13python/cpython:3.13from colesbury:backport-a10152f-3.13colesbury/cpython:backport-a10152f-3.13Copy head branch name to clipboard
Conversation
…hreads (pythongh-137518) There were a few thread-safety issues when profiling or tracing all threads via PyEval_SetProfileAllThreads or PyEval_SetTraceAllThreads: * The loop over thread states could crash if a thread exits concurrently (in both the free threading and default build) * The modification of `c_profilefunc` and `c_tracefunc` wasn't thread-safe on the free threading build. (cherry picked from commit a10152f) Co-authored-by: Sam Gross <colesbury@gmail.com>
|
FYI, the ABI change seems fine to me. |
| self.set = not self.set | ||
|
|
||
|
|
||
| @threading_helper.requires_working_threading() |
There was a problem hiding this comment.
Presumably this test should work regardless of the threading model?
So, maybe just run this test unconditionally?
There was a problem hiding this comment.
I think the InstrumentationMultiThreadedMixin subclasses hang on wasi where there are just no-op pthread stubs.
encukou
left a comment
There was a problem hiding this comment.
The backport looks good to me!
Though, given that 3.13t is experimental and 3.14 is now out, maybe we should start thinking about not doing backports like this any more...
I generally agree, but one of the reasons I decided to backport this is that I think it will make the free-threaded CI more stable as well as fixing a thread-safety issue. |
There were a few thread-safety issues when profiling or tracing all threads via PyEval_SetProfileAllThreads or PyEval_SetTraceAllThreads:
c_profilefuncandc_tracefuncwasn't thread-safe on the free threading build. (cherry picked from commit a10152f)sys._setprofileallthreadsrace condition #137400