Maor Kleinberger <kma...@gmail.com> added the comment:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39622> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
