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 kmaork
Recipients Zhibin Dong, asvetlov, kmaork, yselivanov
Date 2020-02-26.23:00:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I have pushed an update to my PR. While implementing the new solution I made the following list:

Examples for code segments where KeyboardInterrupt must not be raised:
 - Between popping and running a handle from the ready queue (a handle is lost)
 - After running a handle and before a subsequent call_soon finished running (the handle that should have been added by call_soon is lost)
 - After a handle is popped from the _scheduled heap and added to the _ready queue (a handle is lost)

Code segments where KeyboardInterrupt must be raised:
 - During the select call (can be achieved using signal.default_int_handler or signal.set_wakeup_fd)
 - During a running callback (can be achieved using signal.default_int_handler)

I think that while the loop is running, the signal handler should not raise a KeyboardInterrupt by default, as there are at least 3 unsafe code segments, and more might be added in the future. Currently, the only two segments that have to be directly interrupted by a SIGINT are the ones listed above, and I think this behavior should be allowed explicitly.
This is what I did in the new revision of my PR.
Date User Action Args
2020-02-26 23:00:35kmaorksetrecipients: + kmaork, asvetlov, yselivanov, Zhibin Dong
2020-02-26 23:00:35kmaorksetmessageid: <>
2020-02-26 23:00:35kmaorklinkissue39622 messages
2020-02-26 23:00:35kmaorkcreate