Problems with background processes on Windows

[Gabriel Genellina]

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

>
> Hi Tim,
>
>> If you trace through this:
>>     python -m trace --trace communicate.py
>>
>> 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 sleep.py, and hence we shouldn't need to wait for
> it to finish when collecting the standard output of sleep.py, surely?
> (Even explicitly calling sys.stdout.close() in sleep.py 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 stdout.read() won't return,  
because the pipe isn't closed until the last handle to it is closed.

Another option is that subprocess.py 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  
thing.

-- 
Gabriel Genellina