Problems with background processes on Windows

Gabriel Genellina gagsl-py2 at
Sat Mar 28 12:07:57 CET 2009

En Sat, 28 Mar 2009 06:03:33 -0300, geoffbache <geoff.bache at>  

> Hi Tim,
>> If you trace through this:
>>     python -m trace --trace
>> you'll see that it hangs in subprocess in the stdout_thread waiting for
>> stdout to close.
> Thanks for this tip, haven't used this before.
>> I'm not sure I expect this to work as you expect.  When you open a null
>> device, it's just another file handle.  Why should the behavior be
>> different?
> 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.

Another option is that leaks file handles (I remember it  
uses DuplicateHandle).

Unfortunately I won't be able to test either of these until next week.

> Also, the code behaves differently on Linux and Windows, and I haven't
> called anything that is documented as behaving differently on
> different platforms. If it's a genuine OS difference I'd be interested
> in hearing why.

Well, subprocess has completely separate implementations for Windows and  
Linux - it tries hard to hide the differences, but they're not the same  

Gabriel Genellina

More information about the Python-list mailing list