Eryk Sun <eryk...@gmail.com> added the comment:
> That's what Lib/test/win_console_handler.py:39 does. No, that script is currently broken. SetConsoleCtrlHandler(None, False) clears the Ctrl+C ignore flag in the PEB ProcessParameters, which is normally inherited by child processes. But using the CREATE_NEW_PROCESS_GROUP creation flag always causes Ctrl+C to be initially ignored in the process. The intent is to make it a 'background' process by default, to support CMD's `start /b` option. Win32KillTests in Lib/test/test_os.py incorrectly assumes it only has to enable Ctrl+C in the parent process. win_console_handler.py incorrectly assumes it does not have to call SetConsoleCtrlHandler(None, False). This is why test_CTRL_C_EVENT() is currently being skipped. To fix it, win_console_handler.py needs to call SetConsoleCtrlHandler(None, False). > Isn't that what PyConfig.install_signal_handlers is supposed to do? The C runtime's signal() function does not clear the Ctrl+C ignore flag when a SIGINT handler is set. I think Python should. It's expected behavior for POSIX compatibility. > with self.assertRaises(KeyboardInterrupt): > os.kill(os.getpid(), SIG) Unless you know the current process was created in a new process group, it is not correct to call os.kill(os.getpid(), signal.CTRL_C_EVENT). You'd be better off using os.kill(0, signal.CTRL_C_EVENT) and ensuring that Ctrl+C is temporarily ignored in the parent process, if that's in your control. Also, Python 3.8 added raise_signal(), which calls C raise(), so a more reliable way to test just the signal handler is to call signal.raise_signal(signal.SIGINT). This also eliminates needing to synchronize with the console control thread. ---------- _______________________________________ 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
