Message 366007 - Python tracker

➜

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-04-08.21:18:03
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1586380683.2.0.159862469845.issue37127@roundup.psfhosted.org>
In-reply-to

Content
I removed _pending_calls.finishing for multiple reasons: * _PyEval_AddPendingCall() used the C API whereas the caller may not hold the GIL. * bpo-40082: trip_signal() can be called from a thread which has no Python thread state. On Windows, CTRL+C calls trip_signal() in a new thread a each call. I rewrote trip_signal() to only use the PyInterpreterState ("interp") and avoid PyThreadState ("tstate") in PR 19441 to fix bpo-40082. trip_signal() should read and set atomtic variables: don't modify globals without a lock. _PyEval_AddPendingCall() is not fully async-signal safe yet :-/ Using a lock is unsafe in a signal handler.

I removed _pending_calls.finishing for multiple reasons:

* _PyEval_AddPendingCall() used the C API whereas the caller may not hold the GIL.
* bpo-40082: trip_signal() can be called from a thread which has no Python thread state. On Windows, CTRL+C calls trip_signal() in a new thread a each call.

I rewrote trip_signal() to only use the PyInterpreterState ("interp") and avoid PyThreadState ("tstate") in PR 19441 to fix bpo-40082.

trip_signal() should read and set atomtic variables: don't modify globals without a lock. _PyEval_AddPendingCall() is not fully async-signal safe yet :-/ Using a lock is unsafe in a signal handler.

History
Date	User	Action	Args
2020-04-08 21:18:03	vstinner	set	recipients: + vstinner, eric.snow
2020-04-08 21:18:03	vstinner	set	messageid: <1586380683.2.0.159862469845.issue37127@roundup.psfhosted.org>
2020-04-08 21:18:03	vstinner	link	issue37127 messages
2020-04-08 21:18:03	vstinner	create