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