Problems with background processes on Windows

[geoffbache]

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)

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.

To put this another way: what can I do in sleep.py that allows me to
start a time-consuming background process and exit before it's
complete, while not forcing a process that is "communicating" with me
to also wait for this background process before proceeding?

Regards,
Geoff