Repository navigation
os.kill on Windows should accept zero as signal #58685
Description
| BPO | 14480 |
|---|---|
| Nosy | @vstinner, @giampaolo, @bitdancer, @briancurtin, @asvetlov |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2015-03-20.12:26:30.145>
created_at = <Date 2012-04-03.07:23:13.829>
labels = ['easy', 'type-feature', 'library', 'OS-windows']
title = 'os.kill on Windows should accept zero as signal'
updated_at = <Date 2015-03-20.12:26:30.144>
user = 'https://github.com/asvetlov'bugs.python.org fields:
activity = <Date 2015-03-20.12:26:30.144>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2015-03-20.12:26:30.145>
closer = 'vstinner'
components = ['Library (Lib)', 'Windows']
creation = <Date 2012-04-03.07:23:13.829>
creator = 'asvetlov'
dependencies = []
files = []
hgrepos = []
issue_num = 14480
keywords = ['easy']
message_count = 6.0
messages = ['157398', '157418', '157425', '157427', '157430', '238654']
nosy_count = 5.0
nosy_names = ['vstinner', 'giampaolo.rodola', 'r.david.murray', 'brian.curtin', 'asvetlov']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue14480'
versions = ['Python 3.3']
Activity
asvetlov commentedon Apr 3, 2012
Starting from 3.2 Python supports os.kill for Windows.
It process signal.CTRL_C_EVENT and signal.CTRL_BREAK_EVENT, and kills pid for all other signals.
Posix allows to pass zero signal to check pid for existing.
It will be nice to keep that behavior for Windows also.
The patch should be trivial: just don't call TerminateProcess in Modules/posixmodule.c:win32_kill if sig is zero.
briancurtin commentedon Apr 3, 2012
-1
0 has no special meaning on Windows so I'd rather not add another special case for posix emulation. Additionally, 0 unfortunately already means two things as it is: signal.CTRL_C_EVENT and the int 0.
bitdancer commentedon Apr 3, 2012
Hmm. I would think it would be a good idea to have os.kill do posix emulation where that makes sense, it makes cross-platform usage easier. That's what 'kill' with no signal does, right (kills the process, just like the posix default)?
The posix spec says "If sig is 0 (the null signal), error checking is performed but no signal is actually sent. The null signal can be used to check the validity of pid." So *signal* zero doesn't have any special meaning on posix, either, but it does have a special meaning to the kill command.
It seems like it would be nice to add support for that to the windows version, but I'm a little confused. First you say that signal 0 has no special meaning, and then you say that it does (signal.CTRL_C_EVENT). Which is it?
briancurtin commentedon Apr 3, 2012
I meant that in the underlying, such as in the TerminateProcess API, 0 doesn't mean anything special. As is being debated over on bpo-14484 we currently take all integers to be passed to TerminateProcess (the int becomes the killed proc's return code), and two signals to pass to GenerateConsoleCtrlEvent (which is more like posix os.kill).
asvetlov commentedon Apr 3, 2012
There are no
killfunction in Windows API.From my perspective win32_kill was added to emulate posix sibling if possible. If not — better to give another Windows native name to that function.
Really don't see good solution. Maybe better what we can do — declare what os.kill cannot be called with 0 signum on Windows for proc presence checking and note that fact in os.rst.
Terminating process looks like overcomplication. POSIX kill only sends signal to process and nothing more.
vstinner commentedon Mar 20, 2015
I agree, it's not a good idea to support os.kill(pid, 0) on Windows. I reject the issue.
See also the issue bpo-14484.
Windows and LogMonitor (#30643)
Windows and LogMonitor (ray-project#30643)