[issue23948] Deprecate os.kill() on Windows

Change by Eryk Sun : -- resolution: -> rejected stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue23948] Deprecate os.kill() on Windows

John Ehresman added the comment: The original idea was to not use kill on win32 because developers often assume it will work like it does on unix-like OS's -- my claim is while kill could be improved on win32, it still won't support all the things kill can do elsewhere. I don't think

[issue23948] Deprecate os.kill() on Windows

Eryk Sun added the comment: I'd prefer to change os.kill() to take the code path that generates a console control event only when the pid value is negative (i.e. a process group ID), with -1 reserved to send the event to all processes in the console session (i.e. console process group 0).

[issue23948] Deprecate os.kill() on Windows

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg256166 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue23948] Deprecate os.kill() on Windows

Giampaolo Rodola' added the comment: See also #26350. -- nosy: +giampaolo.rodola ___ Python tracker ___ ___

[issue23948] Deprecate os.kill() on Windows

Eryk Sun added the comment: The signal module switched to using an enum for signal values: >>> print(*map(repr, sorted(signal.Signals)), sep='\n') We can use the console API when passed the CTRL_C_EVENT or CTRL_BREAK_EVENT enum. It may be

[issue23948] Deprecate os.kill() on Windows

John Ehresman added the comment: Part of the issue here is that GenerateConsoleCtrlEvent doesn't work like kill w/ SIGINT does on unix -- it only works if the the target process id is 0 and then it generates the signal in all processes that share the console. An alternate proposal here is to

[issue23948] Deprecate os.kill() on Windows

John Ehresman added the comment: GenerateConsoleCtrlEvent has different limitations for CTRL_BREAK_EVENT and CTRL_C_EVENT according to MSDN; I was referring to the CTRL_C_EVENT limitations. Which python level signal handler will CTRL_BREAK_EVENT trigger? --

[issue23948] Deprecate os.kill() on Windows

eryksun added the comment: it only works if the the target process id is 0 and then it generates the signal in all processes that share the console. You can target a process group, which is a subset of the console's attached processes. That's why the console host, conhost.exe, routes

[issue23948] Deprecate os.kill() on Windows

eryksun added the comment: Which python level signal handler will CTRL_BREAK_EVENT trigger? The CRT maps it to a non-standard signal, SIGBREAK (21). It's defined in the signal module. GenerateConsoleCtrlEvent has different limitations for CTRL_BREAK_EVENT and CTRL_C_EVENT according to

[issue23948] Deprecate os.kill() on Windows

John Ehresman added the comment: Interesting -- I didn't know about removing the ignore flag in the child process. The question is whether this is close enough to the kill w/ SIGINT behavior on unix to use the same name. I think that there are enough differences to warrant a Windows

[issue23948] Deprecate os.kill() on Windows

New submission from John Ehresman: os.kill() on Windows cannot act like it does on non-windows platforms because of differences in the underlying platforms. I think only kill() with a signal number of 9 (terminate process unconditionally) and a signal number of 0 (test to see if process

[issue23948] Deprecate os.kill() on Windows

Steve Dower added the comment: This feels like an unnecessary incompatibility between the platforms. I'd rather change the parameter values for CTRL+C events so we can distinguish when someone calls with that and then fix it internally on Windows. --