Problems with background processes on Windows

Gabriel Genellina gagsl-py2 at
Mon Mar 30 06:57:18 CEST 2009

Gabriel Genellina <gagsl-py2 <at>> writes:
> En Sat, 28 Mar 2009 06:03:33 -0300, geoffbache <geoff.bache <at>>  
> escribió:
> >
> > Well yes, but the point is surely that the standard output of the
> > background sleeping process is pointed to a different location? (you
> > can replace the null device with a file name of your choice and the
> > point is the same.) This process should not have any connection to the
> > standard output of, and hence we shouldn't need to wait for
> > it to finish when collecting the standard output of, surely?
> > (Even explicitly calling sys.stdout.close() in doesn't seem
> > to help)
> Thesis: When the subprocess module creates the child process, it inherits  
> the stdin/stdout/stderr handles from its parent (even if its own  
> stdin/stdout/stderr are redirected; they're different). Until the  
> grandchild process finishes, the grandparent won't return,  
> because the pipe isn't closed until the last handle to it is closed.

I've confirmed the above description.

--- begin ---
import subprocess,os

p1 = subprocess.Popen(["python", ""], 
      stderr=open(os.devnull, "wt"),
print p1.communicate()
--- end ---

--- begin ---
import subprocess,sys,os,msvcrt

    ["python", "", str(msvcrt.get_osfhandle(sys.stdout.fileno()))], 
    stdout=open(os.devnull, "wt"),
    stderr=open(os.devnull, "wt"),
    stdin=open(os.devnull, "rt"))
print "exit"
--- end ---

--- begin ---
import sys, win32api, time, os

with open("","wt") as f: f.write("%d" % os.getpid())
--- end ---

p2 has to close the inherited file handle corresponding to p1's stdout. Then, 
when p1 itself finishes, the writing end of the pipe is actually closed and p0 
can continue.

('exit\r\n', None)

C:\TEMP\subp>tasklist | find "python.exe"
python.exe                  3018                         0     4.304 KB

I'm unsure this could be considered a bug in subprocess - the documentation 
says that parameter close_fds=True is not supported on Windows (so, the child 
process inherits all open files, and this includes the parent's 

At the end, this is due to the fact that file handles 0, 1, 2 have no special 
significance on Windows - it's the C runtime library which makes such things 
special, not the OS.

More information about the Python-list mailing list