subprocess.Popen does not close pipe in an error case

[Steven K. Wong]

On Jan 6, 10:30 am, Nobody <nob... at nowhere.com> wrote:
> I think that you should close prog1.stdout here. Otherwise, there will
> be two readers on the pipe (the calling process and prog2). Even if one of
> them dies, there's always the possibility that the caller might eventually
> decide to read prog1.stdout itself. If you close it in the caller, when
> prog2 terminates there will be no readers, and prog1 will get SIGPIPE (or
> write() will fail with EPIPE if SIGPIPE is handled).

Thanks for raising a great point, that prog1.stdout is also readable
by the calling process, not just by prog2. Therefore, I agree it makes
sense to explicitly call prog1.stdout.close() in the given code (say
right after the creation of prog2).

Suppose now all the prog1.poll() calls/loop are replaced by a single
prog1.wait(). Without the explicit prog1.stdout.close(), prog1.wait()
will not return, so the calling process still hangs. Because calling
prog1.wait() means that the calling process will naturally never read
prog1.stdout, I would argue that prog1.wait() should close the pipe
before actually waiting for prog1 to exit. Makes sense?