[issue37127] Handling pending calls during runtime finalization may cause problems.
STINNER Victor
report at bugs.python.org
Wed Mar 18 14:10:40 EDT 2020
STINNER Victor <vstinner at python.org> added the comment:
> pending->finishing was addd in bpo-33608 by the change: commit 842a2f07f2f08a935ef470bfdaeef40f87490cfc
Since this change, Py_AddPendingCall() now requires the thread to have a Python thread state: it is used if pending->finishing is non-zero.
The function documentation says:
"This function doesn’t need a current thread state to run, and it doesn’t need the global interpreter lock."
https://docs.python.org/dev/c-api/init.html#c.Py_AddPendingCall
The current implementation seems to contradict the documentation.
We may update the documentation to replace "doesn't need" with "requires" (a Python thread state).
Or the implementation can use PyGILState_Ensure() and PyGILState_Release() to create a temporary Python thread state if the thread doesn't have one.
Removing pending->finishing would only partially fix the issue. With PR 19061, tstate is required to access "ceval" structure.
trip_signal() called by the C signal handler has a similar issue: it only requires non-NULL tstate if pending->finishing is non-zero.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37127>
_______________________________________
More information about the Python-bugs-list
mailing list