classification
Title: missing return in win32_kill?
Type: behavior Stage:
Components: Windows Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: asvetlov, 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 2019-02-24 22:55 by BreamoreBoy.

Messages (16)
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.
History
Date User Action Args
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