This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients eric.snow, vstinner
Date 2020-03-18.18:10:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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."

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.
Date User Action Args
2020-03-18 18:10:40vstinnersetrecipients: + vstinner, eric.snow
2020-03-18 18:10:40vstinnersetmessageid: <>
2020-03-18 18:10:40vstinnerlinkissue37127 messages
2020-03-18 18:10:40vstinnercreate