This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: missing return in win32_kill?
Type: behavior Stage:
Components: Windows Versions: Python 3.11, Python 3.10, Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: asvetlov, eryksun, iritkatriel, jpe, pitrou, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
Priority: normal Keywords:

Created on 2012-04-03 14:10 by pitrou, last changed 2022-04-11 14:57 by admin.

Messages (20)
msg157419 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-03 14:10
Here is an excerpt from the os.kill implementation under Windows (in win32_kill(), posixmodule.c):

    if (sig == CTRL_C_EVENT || sig == CTRL_BREAK_EVENT) {
        if (GenerateConsoleCtrlEvent(sig, pid) == 0) {
            err = GetLastError();
            PyErr_SetFromWindowsErr(err);
        }
        else
            Py_RETURN_NONE;
    }

It seems there is a missing return in the first branch, when GenerateConsoleCtrlEvent() fails.
msg157421 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-04-03 14:19
Antonie, you right.
msg157422 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-03 14:19
I can't find where we talked about this, maybe just IRC, but that's there (perhaps poorly) as a special case.

0 is 0, but signal.CTRL_C_EVENT is also 0. We try the signal version first then fall back to TerminateProcess.

I was just looking at this myself and it's not great. I actually wish we could change what signal.CTRL_C_EVENT means, or maybe add a flag to determine if the second parameter is supposed to be a return code or a signal? I'm open to anything.
msg157424 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-03 14:24
> I can't find where we talked about this, maybe just IRC, but that's
> there (perhaps poorly) as a special case.
> 
> 0 is 0, but signal.CTRL_C_EVENT is also 0. We try the signal version
> first then fall back to TerminateProcess.

Then why set the error?
That said, abruptly killing another process and making it return 0
sounds a bit perverted.
msg157426 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2012-04-03 14:38
I don't remember exactly why, but it can be removed. It may have just been left in while I was debugging it.

As for the second point, why else are you calling os.kill if you don't want to kill the given process? I don't disagree that it's on the perverse side, but that's the functionality available. Perhaps we should *not* have the fallback and only operate on the signals?
msg157428 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-03 15:05
> As for the second point, why else are you calling os.kill if you don't
> want to kill the given process? I don't disagree that it's on the
> perverse side, but that's the functionality available. Perhaps we
> should *not* have the fallback and only operate on the signals?

I just meant that exiting with 0 isn't exactly expected when a process
is forcibly killed (0 meaning success, as far as I know).
msg157429 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-03 15:07
I would think that if Windows doesn't support a specific signal, os.kill should raise a ValueError.  But I'm an outsider here, I know nothing about how Windows works for this except what I'm reading here.  

To answer your question: there are many reasons to call kill on unix, and only a few of them kill the process.  Kill is just an historical name, it really means 'send a signal'.

In a broader picture, I think that os.kill calls should have the same "meaning", insofar as possible, on both linux and windows.  Having a single API with the same syntax but different semantics on different platforms sounds bad to me.
msg222918 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-13 12:07
@Zach can you add anything to this?
msg223684 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2014-07-22 19:50
It looks like we have a bit of a mess here.  2.7 has a return there (and thus doesn't fall back to TerminateProcess if GenerateConsoleCtrlEvent fails), added 40 commits after the initial implementation in b1c00c7d3c85, but 3.x was never changed so 2.7 and 3.x have behaved differently from the the time it was implemented.  Which version is right, or is it too late to change either one and 3.x should just remove the unused error setting?  An interesting possibility might be to convert the signal.CTRL_* values to an enum, and use that as a way to distinguish between ``0`` and ``signal.CTRL_C_EVENT``.  I suspect that might become rather hairy, though.

Either way, I don't think os.kill can promise much more than "try to make the specified process die" on Windows; signals are just so crippled on Windows that that's about all you can do with them anyway.  It might not hurt for the docs to try to make that clearer.
msg223739 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-07-23 13:45
I understand that os.kill(pid, sig) should call TerminateProcess() or GenerateConsoleCtrlEvent() depending on the value of sig.

The problem is that these two functions are very different. A process can set a control handler for CTRL_C_EVENT and CTRL_BREAK_EVENT, so can decide how to handle GenerateConsoleCtrlEvent() event.

TerminateProcess() kills the process with the specified exit code.

To me it looks wrong to call TerminateProcess() with a signal number or event for the exit code!? We need to expose TerminateProcess() as a new Python function, os.TerminateProcess(pid, exitcode) for example.

os.kill(pid, sig) should raise a ValueError if sig is not CTRL_C_EVENT nor CTRL_BREAK_EVENT.
msg236320 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2015-02-20 19:02
#14480 "os.kill on Windows should accept zero as signal" references this.  It seems that we either go all the way and change the code as Victor has suggested or keep the status quo and change the docs as Zach has said.  Thoughts?
msg240809 - (view) Author: John Ehresman (jpe) * Date: 2015-04-13 23:40
I think at a minimum, a return should be added in the cases that call GenerateConsoleCtrlEvent and it fails.

Here's a more radical proposal, though: deprecate kill() on Windows and add a function that calls GenerateConsoleCtrlEvent and another that calls TerminateProcess.  The rationale is that the two do act quite a bit differently than kill does on non-Windows systems do and it's a bad idea to try to provide cross-platform functionality when it can't be done.  kill() on non-Windows systems would be left alone.
msg240815 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-04-14 00:31
I think what I'd rather do is deprecate the use of os.kill (on Windows) with a signal other than CTRL_C_EVENT and CTRL_BREAK_EVENT, document very clearly that os.kill is strictly for sending signals, and add os.terminate to implement TerminateProcess.
msg240819 - (view) Author: John Ehresman (jpe) * Date: 2015-04-14 00:52
A problem with os.kill with CTRL_C_EVENT is that CTRL_C_EVENT == 0 and on unix kill w/ a signal number of 0 is how you test to see if a process is running.  This means that code written on unix to see if a process exists will try to send a ctrl-c to the other process; it will fail because GenerateConsoleCtrlEvent is so limited but the error message is likely to be confusing.

Not using the kill() name also means that developers coming from unix won't expect other signal numbers to work.
msg240824 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-04-14 01:36
That's a fair point.  So to make my plan work, we'd really need a good
way to differentiate CTRL_C_EVENT and 0.  If anybody has any good
ideas on that, I still like my plan.  If not, I'm afraid I have to
agree that os.kill will need to go down as doomed by Windows'
incompatibility with the rest of the world.
msg240912 - (view) Author: John Ehresman (jpe) * Date: 2015-04-14 15:33
I've created issue #23948 for the idea of deprecating os.kill().

Is a patch needed for adding a return in the error case?  It's that way in 2.7 and I'm struggling to come up with a reason why it shouldn't be added other than strict backward compatibility.
msg408328 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-12-11 18:24
That piece of code is still there, the function is now called os_kill_impl.
msg408337 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-12-11 21:16
The details of os.kill() on Windows have been discussed extensively for years in various issues such as bpo-26350, bpo-23948, and bpo-42962. But the problem of the missing return statement is always overwhelmed by discussion of the egregiously bad design of this function and its misuse, which depends on bugs in WinAPI GenerateConsoleCtrlEvent() when passed a PID that is not a process group ID and/or not attached to the console.
msg408454 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-12-13 13:48
IMO trying to mimic POSIX behavior on Windows in the single function os.kill() was a bad design idea. Windows should have its own specific function.
msg408487 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-12-13 22:36
> Windows should have its own specific function.

Either that or mimic it properly. Having a single function that requires 
different parameters based on OS is a very user-hostile design.

If someone wants to shepherd it through the process, I'd support either 
making the typical POSIX values do sensible equivalents on Windows (as 
best possible), or adding a new function entirely and deprecating all 
use of the current one on Windows. Those are the only ways to lead 
people into writing code that works well on all platforms.

(My *real* preference is that people stop trying to kill applications ;) 
and try to set up a safe communication channel instead, but I know it's 
often unavoidable. Having common parameters that do the Right Things on 
all platforms is next best.)
History
Date User Action Args
2022-04-11 14:57:28adminsetgithub: 58689
2021-12-13 22:46:11iritkatrielsetversions: + Python 3.9, Python 3.10, Python 3.11, - Python 3.7
2021-12-13 22:36:29steve.dowersetmessages: + msg408487
2021-12-13 13:48:55vstinnersetmessages: + msg408454
2021-12-11 21:16:15eryksunsetmessages: + msg408337
versions: + Python 3.7, - Python 3.9, Python 3.10, Python 3.11
2021-12-11 21:15:52eryksunsetmessages: - msg408336
2021-12-11 21:15:13eryksunsetnosy: + eryksun
messages: + msg408336
2021-12-11 21:00:33eryksunlinkissue42962 superseder
2021-12-11 18:24:31iritkatrielsetnosy: + iritkatriel

messages: + msg408328
versions: + Python 3.9, Python 3.10, Python 3.11, - Python 2.7, Python 3.4, Python 3.5
2019-02-24 22:55:37BreamoreBoysetnosy: - BreamoreBoy
2015-04-14 15:33:37jpesetmessages: + msg240912
2015-04-14 01:36:46zach.waresetmessages: + msg240824
2015-04-14 00:52:53jpesetmessages: + msg240819
2015-04-14 00:31:50zach.waresetmessages: + msg240815
2015-04-13 23:40:53jpesetnosy: + jpe
messages: + msg240809
2015-02-20 19:02:32BreamoreBoysetnosy: + steve.dower
messages: + msg236320
2014-07-23 13:45:29vstinnersetnosy: + vstinner
messages: + msg223739
2014-07-22 19:50:32zach.waresetmessages: + msg223684
2014-07-13 13:23:22brian.curtinsetnosy: - brian.curtin
2014-07-13 12:07:14BreamoreBoysetnosy: + BreamoreBoy, zach.ware

messages: + msg222918
versions: + Python 3.4, Python 3.5, - Python 3.2, Python 3.3
2012-04-03 15:07:46r.david.murraysetnosy: + r.david.murray
messages: + msg157429
2012-04-03 15:05:12pitrousetmessages: + msg157428
2012-04-03 14:38:45brian.curtinsetmessages: + msg157426
2012-04-03 14:24:09pitrousetmessages: + msg157424
2012-04-03 14:19:59brian.curtinsetmessages: + msg157422
2012-04-03 14:19:02asvetlovsetmessages: + msg157421
2012-04-03 14:10:25pitroucreate