William Schwartz <wkschwa...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue42962> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com