It would be really handy to add a way to portably kill process groups of 
a process spawned with subprocess.Popen. My project starts a process, 
which then starts other long running processes. Because of this process 
tree, there's no way for me to portably kill all of those processes. 
Would it be possible to extend subprocess with these features? I did 
find someone who's already implemented this [1], and it's working well 
in my project. There was some discussion about adding this, but it seems 
no one actually committed a patch to implement it.

Anyway, I've attached a patch against python3.0's svn branch that 
implements this. I don't have access to windows, so I'm not able to make 
sure that the TerminateJobObject is correct, and works.

[1]: http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/
[2]: http://mail.python.org/pipermail/python-list/2008-April/487588.html

I suspect that on Windows, TerminateJobObject won't work with a handle
returned by CreateProcess.
A solution could look like 
    http://www.mobzystems.com/code/killprocesstree.aspx

> I suspect that on Windows, TerminateJobObject won't work 
> with a handle returned by CreateProcess.

TerminateJobObject works with CreateJobObject and AssignProcessToJobObject. The following code (from your patch) should call AssignProcessToJobObject (and CreateJobObject if there is no job yet):

+                    if not mswindows:
+                        os.setpgid(0, 0)

erickt: can you fix your patch?

A strong +1 on adding this feature.

I was wondering... what if process A runs a subprocess B which runs a subprocess C. Is C still considered a children of A and gets killed as well?

Does os.setpgid() takes care of such a thing? What about Windows instead?

Note that the setpgid creation part is now somewhat redundant with Popen's start_new_session flag (which calls setsid). Also, this should probably be an option, since with that patch every subprocess is in its own process group.

> I was wondering... what if process A runs a subprocess B which runs a
> subprocess C. Is C still considered a children of A and gets killed as
> well?

No.
When setpgid/setsid is called, a new group is created, so process C will be not be part of the same group as B.

Using a Windows job object should be paired with the creation flag CREATE_SUSPENDED. Callers may also need CREATE_BREAKAWAY_FROM_JOB, but setting that creation flag shouldn't be integrated into Popen.

The child has to be created suspended to ensure it doesn't spawn another process and exit before it's added to the job. Once it's in the job, call ResumeThread to start it. 

On Windows Vista and 7, the child may need to break away from Python's current job, if allowed. These older versions of Windows don't implement nested jobs, so adding the child to a job will fail if it's already in one. The job used by py.exe for python.exe isn't a problem in this case since it's configured for child processes to automatically break away, but python.exe may have been started directly and added to a job that's not configured for silent breakaway.

this is part of a chain of other related issues.  the interesting thing in the patch in here is the potential feature to have send_signal/terminate/kill be able to optionally kill a process group.

the logic as is in the patch in this issue is dangerous as often the calling process _is_ the pgrp leader and would be killed.  we _never_ want the subprocess signaling methods to kill the current process as that would be surprising to users.