Eryk Sun added the comment: >From the linked issue:
> proc.send_signal(CTRL_C_EVENT) raises the KeyboardInterrupt > in both the original and subprocess on Windows GenerateConsoleCtrlEvent takes process group IDs, so it should have been used to implement os.killpg, not os.kill. If you call it on a process ID that's attached to the console that isn't also a group ID (i.e. the group leader), then it defaults to group 0, which includes every process that's attached to the console. Popen.send_signal should only send CTRL_C_EVENT or CTRL_BREAK_EVENT when the child process was created with CREATE_NEW_PROCESS_GROUP in its creationflags. Also, since kill() falls back on TerminateProcess, for added safety send_signal also needs to call poll() instead of using returncode because Windows reuses process IDs. Also, to avoid confusion, it should be noted that CTRL_C_EVENT will be ignored by a process in a new group unless said process manually enables Ctrl+C handling by calling SetConsoleCtrlHandler(NULL, FALSE). This setting will be inherited by child processes. In the long run I think it would be better to clarify this by implementing os.killpg on Windows using GenerateConsoleCtrlEvent, with support for CTRL_C_EVENT, CTRL_BREAK_EVENT, SIGINT, and SIGBREAK. Deprecate using os.kill to send console control events. There is no Windows API to send a console control event to a particular process ID. ---------- nosy: +eryksun _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29971> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
