Message362751
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:35 | kmaork | set | recipients:
+ kmaork, asvetlov, yselivanov, Zhibin Dong |
2020-02-26 23:00:35 | kmaork | set | messageid: <1582758035.48.0.927344050427.issue39622@roundup.psfhosted.org> |
2020-02-26 23:00:35 | kmaork | link | issue39622 messages |
2020-02-26 23:00:35 | kmaork | create | |
|