[issue1021318] PyThreadState_Next not thread safe

STINNER Victor added the comment: I marked bpo-26461 as a duplicate of this issue. -- ___ Python tracker ___ ___

[issue1021318] PyThreadState_Next not thread safe

STINNER Victor added the comment: See also bpo-35370: "Add _PyEval_SetTrace(tstate, func, arg) function". -- ___ Python tracker ___

[issue1021318] PyThreadState_Next not thread safe

Eric Snow added the comment: On Wed, Dec 11, 2019 at 7:02 AM STINNER Victor wrote: > We may have to fix this API first, and clarify the scope of the different > locks. +1 -- ___ Python tracker

[issue1021318] PyThreadState_Next not thread safe

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1021318] PyThreadState_Next not thread safe

STINNER Victor added the comment: 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. --

[issue1021318] PyThreadState_Next not thread safe

Julien Danjou added the comment: 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? --

[issue1021318] PyThreadState_Next not thread safe

Julien Danjou added the comment: Yes, that's the one  -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1021318] PyThreadState_Next not thread safe

STINNER Victor added the comment: > We'd simply need to provide a new API to lock/unlock the interpreter's mutex. Are you talking about this lock? #define HEAD_LOCK(runtime) \ PyThread_acquire_lock((runtime)->interpreters.mutex, WAIT_LOCK) #define HEAD_UNLOCK(runtime) \

[issue1021318] PyThreadState_Next not thread safe

Change by STINNER Victor : -- nosy: +eric.snow, pitrou, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue1021318] PyThreadState_Next not thread safe

STINNER Victor added the comment: I reopened the issue and changed the version to 3.9. -- resolution: out of date -> status: closed -> open versions: -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker

[issue1021318] PyThreadState_Next not thread safe

Julien Danjou added the comment: It'd be great if you could reopen it. I'm interested in fixing it properly. It's impossible to "solve" in Python 2 since the head mutex is not accessible (it's static in pystate.c) but this is doable with Python 3 (yay). We'd simply need to provide a new API

[issue1021318] PyThreadState_Next not thread safe

STINNER Victor added the comment: > 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. This issue is closed. Would you be able to write a reproducer script? If yes, maybe open a

[issue1021318] PyThreadState_Next not thread safe

Julien Danjou added the comment: 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

[issue1021318] PyThreadState_Next not thread safe?

Mark Lawrence breamore...@yahoo.co.uk added the comment: No reply to msg82072. -- nosy: +BreamoreBoy resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1021318

[issue1021318] PyThreadState_Next not thread safe?

Daniel Diniz aja...@gmail.com added the comment: Can someone take a look a this and either close or propose what to do? -- nosy: +ajaksu2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1021318