Repository navigation
Closed
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancementA feature request or enhancement
Description
| BPO | 1220212 |
|---|---|
| Nosy | @tim-one, @loewis, @tebeka, @tiran, @tpn, @DinoV, @voidspace, @briancurtin |
| Files |
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 = 'https://github.com/briancurtin'
closed_at = <Date 2010-04-12.18:11:07.992>
created_at = <Date 2005-06-14.09:11:53.000>
labels = ['interpreter-core', 'type-feature']
title = 'os.kill on windows'
updated_at = <Date 2010-04-12.18:11:07.991>
user = 'https://github.com/tebeka'bugs.python.org fields:
activity = <Date 2010-04-12.18:11:07.991>
actor = 'brian.curtin'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2010-04-12.18:11:07.992>
closer = 'brian.curtin'
components = ['Interpreter Core']
creation = <Date 2005-06-14.09:11:53.000>
creator = 'tebeka'
dependencies = []
files = ['6690', '6691', '16739', '16765']
hgrepos = []
issue_num = 1220212
keywords = ['patch']
message_count = 30.0
messages = ['48455', '48456', '48457', '48458', '48459', '48460', '48461', '48462', '48463', '48464', '59787', '59800', '62468', '101774', '101775', '101777', '101828', '101846', '101847', '101851', '101970', '101973', '102184', '102200', '102202', '102213', '102375', '102379', '102385', '102965']
nosy_count = 13.0
nosy_names = ['tim.peters', 'loewis', 'nnorwitz', 'tebeka', 'andersjm', 'techtonik', 'christian.heimes', 'kap4020', 'Technologov', 'trent', 'dino.viehland', 'michael.foord', 'brian.curtin']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1220212'
versions = ['Python 2.7', 'Python 3.2']Metadata
Metadata
Assignees
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancementA feature request or enhancement
Activity
tebeka commentedon Jun 14, 2005
This patch enables os.kill on windows. This way there
will be an "out of the box" way to kill process on windows.
Basically kill calls TerminateProcess and the "signal"
paramer will be the process return code.
Don't have CVS access today so I'm sending the whole
files in a zip (sorry).
Also some config wizard need to change the winsows
configuration and set HAVE_KILL.
loewis commentedon Jul 11, 2005
Logged In: YES
user_id=21627
Converted to unified diff.
kap4020 commentedon Jul 6, 2006
Logged In: YES
user_id=1537118
So is there a reason this isn't in the latest Python? The
patch is tiny.
nnorwitz commentedon Jul 6, 2006
Logged In: YES
user_id=33168
Karl, can you test this patch and verify it works? It would
be especially helpful to test on Win9x and WinNT variants.
Are there tests included? Is there a doc patch? These are
some of the potential reasons this isn't included. As for
me, I can't test this patch (no windows), so it's a
non-starter. If you'd like to help out, we could use the help.
loewis commentedon Jul 6, 2006
Logged In: YES
user_id=21627
As is, the patch has two major problems:
TerminateProcess expects a process handle, not a process
ID. This makes the patch pretty useless: To kill a process
other than yourself, you need to call OpenProcess first (or
obtain a process handle in some other way, e.g. by having
created it).
if the call fails, it uses posix_error to report the
problem. However, posix_error expects that errno is set,
which isn't the case here.
Furthermore, this patch would duplicate
_subprocess.TerminateProcess, which already exposes
TerminateProcess (plus allowing to specify the exit code).
So in its current form, I think the patch should be rejected.
tebeka commentedon Jul 9, 2006
Logged In: YES
user_id=358087
IIRC (the patch was done a long time ago), Python uses the
process handle as the process id, I've tested the code and
it worked.
I agree that the patch need more work, mainly the error
return value.
At least on Python 2.4.3, TerminateProcess is not exposed by
_subprocss (or subprocess).
I still think that having a way to kill a process OOTB on
win32 is very important, pretty swamped right now but I'll
try to improve the patch.
loewis commentedon Jul 9, 2006
Logged In: YES
user_id=21627
"Python uses the process handle as process id" makes no real
sense - Win32 works differently. You can't terminate a
process without a handle, and you can't just "use" the
process id as the handle. Perhaps some use cases for the API
would need to be defined first.
tim-one commentedon Jul 9, 2006
Logged In: YES
user_id=31435
Martin, FYI, on Windows the os.spawn() functions return the
process handle, so that's the natural use case: killing a
process spawned by Python's os.spawn*(). This is a little
confusing because the spawn() functions are documented as
returning "the process ID", and verbiage inside the spawn
docs explains that it doesn't really mean "process ID" on
Windows.
loewis commentedon Jul 9, 2006
Logged In: YES
user_id=21627
Ah, ok. Given that _subprocess already offers that
functionality, I'm still -1 on adding it to "nt". Adding
some kind of OpenProcess might be more useful, but then,
people can get to all these functions through ctypes, as well.
tim-one commentedon Jul 9, 2006
Logged In: YES
user_id=31435
Well, os.waitpid() on Windows also takes a process handle.
This was (of course) deliberate, so that os.waitpid() could
use the thingie returned by os.spawn() on Windows. If
os.kill() were ever added to Windows, I think it would be
quite natural for it to take a process handle too, and for
the same reason (Python code mixing os.{spawn,waitpid,kill}
could be the same across platforms). Zope's ZODB relies on
mixing spawn and waitpid this way, and Zope's ZRS implements
its own kill function on Windows so that the rest of the
Python code can just do kill(id) on all platforms (where
idis always something obtained from os.spawn()).tiran commentedon Jan 12, 2008
This should be implemented differently. Users should substitute their
popen and exec calls with subprocess. The subprocess.Popen class should
gain two new methods terminate() and send_signal(int) where send_signal
is restricted to SIGKILL (+SIGTERM ?) on Windows. The idea was discussed
on the Python dev list early last year.
tebeka commentedon Jan 12, 2008
The Popen(...).terminate() works only if I'm the one who started the
process. However there are cases where I want to kill all running python
processes. The pids to be killed will come from somewhere else (ps,
plist, ...).
Technologov commentedon Feb 16, 2008
Yes, this feature would be very important for me too...
Anybody knows, _when_ it will be integrated into Python ?
If this bugzilla supports email notifications, Please add me as "CC" for
this bug.
-Technologov
9 remaining items
voidspace commentedon Apr 2, 2010
After discussion with Brian it seems like it should be possible for os.kill(...) on Windows to support both pids *and* process handles. This seems ideal.
briancurtin commentedon Apr 2, 2010
Michael, do you have an example of something which returns a handle? This current patch doesn't work with handles, but it wouldn't be hard to add it. I could make it work with the _handle object of a Popen object, but you could just as easily call os.kill on the pid of the Popen object. I don't know of any Python-wide handle object...I know subprocess has it's own, and don't really know what other functions are returning handles.
Anyways, this patch includes an additional test script which uses ctypes to setup a console control handler, and CTRL_BREAK_EVENT is tested successfully. However, CTRL_C_EVENT is not. See http://msdn.microsoft.com/en-us/library/ms686016%28v=VS.85%29.aspx for details, but I'm not able to get the subprocess to work with CTRL+C. Calling SetConsoleCtrlHandler(NULL, FALSE) either in the script, test_os, or in _subprocess.c does not change anything, although it seems that it should. The CTRL_C_EVENT test is currently skipped in the patch until I can figure that out.
voidspace commentedon Apr 2, 2010
According to earlier discussion in this issue os.spawn() return process handles on Windows.
briancurtin commentedon Apr 2, 2010
Committed to trunk in r79633 after talking with Michael about it. I'll forward port it after the 2.7 beta goes out.
techtonik commentedon Apr 5, 2010
FAQ should be updated http://www.python.org/doc/faq/windows/#how-do-i-emulate-os-kill-in-windows
briancurtin commentedon Apr 5, 2010
How about something like this patch?
techtonik commentedon Apr 5, 2010
Seems good to me, even though I'd rewrite some parts like this:
+ Prior to Python 2.7 and 3.2, you can use linksomehow:`ctypes` to
terminate a process::
...
In newer Python versions :func:`os.kill` works on Windows with the
additional feature of being able to send CTRL+C and CTRL+BREAK to
console subprocesses that understand these signals.
...
anatoly t.
On Mon, Apr 5, 2010 at 6:38 PM, Brian Curtin <[email protected]> wrote:
briancurtin commentedon Apr 12, 2010
Ported to py3k in r80008.
FAQ text updated in r80009 and r80010.