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 -- http://mail.python.org/mailman/listinfo/python-list
