> 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.