[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)

[William Schwartz]

William Schwartz <wkschwartz at gmail.com> added the comment:

>For a new process group, the cancel event is initially ignored, but the break event is always handled. To enable the cancel event, the process must call SetConsoleCtrlHandler(NULL, FALSE), such as via ctypes with kernel32.SetConsoleCtrlHandler(None, False). I think the signal module should provide a function to enable/disable Ctrl+C handling without ctypes, and implicitly enable it when setting a new SIGINT handler.

That's what Lib/test/win_console_handler.py:39 does. What I don't understand is why that's necessary. Isn't that what PyConfig.install_signal_handlers is supposed to do?

Which brings me to how I ended up here in the first place: I wanted to write a test that PyConfig.install_signal_handlers is set in an embedded instance of Python I'm working with. In outline, the following test works on both Windows and macOS *except on Windows running under Tox*.

@unittest.removeHandler
def test_signal_handlers_installed(self):
    SIG = signal.SIGINT
    if sys.platform == 'win32':
        SIG = signal.CTRL_C_EVENT
    with self.assertRaises(KeyboardInterrupt):
        os.kill(os.getpid(), SIG)
        if sys.platform == 'win32':
            time.sleep(.1)  # Give handler's thread time to join

Using SetConsoleCtrlHandler if I detect that I'm running on Windows under Tox would, if I understand correctly, hide whether PyConfig.install_signal_handlers was set before the Python I'm running in started, right? (I know this isn't the right venue for discussing my embedding/testing problem. But maybe the use case informs the pending discussion of what to do about os.kill's semantics.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42962>
_______________________________________