New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change "with subprocess.Popen():" (context manager) to ignore broken pipe error #67758
Comments
The Popen.communicate() method ignores broken pipe error when writing to stdin. I propose to modify Popen.__exit__() to do the same in Python 3.5. Attached patch implements this suggestion and document it. I added this paragraph to Popen doc: "The context manager ignores broken pipe errors when closing the process’s stdin: call explicitly proc.stdin.flush() and proc.stdin.close() to get broken pipe errors." So it's still possible to get broken pipe errors if you need them. Do you know applications or libraries which rely on broken pipe errors and do something different than just ignoring them? I prefer to leave Python 3.4 unchanged to avoid subtle behaviour changes in minor Python releases. See also: |
I left some minor comments on the documentation. As a side effect of your rearranging of _stdin_write(), I think it would fix the bug with communicate() leaking a BrokenPipeError and leaving a zombie when there is less than a buffer’s worth of data to send. |
Do you want to modify IOBase.__exit__ to ignore I/O errors in close()? I think such changes should be discussed in Python-Dev. |
Nope. On files, you want to want to know if your data has been fully written. For a subprocess, it's different. You only expect best effort. The BrokenPipeError exception is raised by Python when an OS function fails with EPIPE. This exception has the same purpose than the SIGPIPE signal: warn the application that it's now useless to send more data, the consumer will ignore it. By the way, since Python checks the result of *all* OS functions, SIGPIPE is simply ignored. SIGPIPE and EPIPE have the same purpose. In the subprocess module, if we get BrokenPipeError, it means that the child process stopped reading from stdin (closed it or the process already exited). Popen.communicate() must close stdin, so why would we pass BrokenPipeError to the caller? It's useless, we just stop writing and close the pipe. Since Popen.__exit__() also closes stdin, I use the same rationale: it useless to pass BrokenPipeError to the caller. The caller expects that the process exited. Anyway, we closed all pipes, it's not more possible to communicate with the child process. The following example displays "is proc stdin closed? True": import subprocess, sys
args = [sys.executable, '-c', 'pass']
proc = subprocess.Popen(args, stdin=subprocess.PIPE)
try:
with proc:
proc.stdin.write(b'x' * (2**20))
except BrokenPipeError:
pass
print("is proc stdin closed?", proc.stdin.closed) See also: "Why does SIGPIPE exist?" |
New patch to fix the bug seen by Serhiy.
Oh, I forgot to explain that TextIOWrapper.close() closes the buffered file even if flush() raised an exception. BufferedWriter.close() does the same. So stdin.close() always closes the text (binary or text, buffered or not). It's not more possible to use stdin after stdin.close(), even if stdin.close() raised an exception. |
I don't see a difference between buffered file and Popen object. Both are useless |
I thought about different solution:
But your approach looks working too, |
Your solution is different: I would prefer to also ignore broken pipe errors on close(). I'm not sure that close() can raise a BrokenPipeError in practice. |
Of course all this code should be inside try/except block that ignores a |
After understanding the Windows test failure in bpo-21619, I am starting to believe that code relying on a BrokenPipeError or EPIPE is flawed. It is an inherent unavoidable race condition with the receiving end of the pipe, as long as another thread or process is involved, which is always the case for the subprocess module. Another way of looking at it is that there is no guarantee that your data will have been (or will be) received, even if stdin.close() succeeds and does not raise EPIPE or similar. This is because piped data is buffered by the OS. So the proposed change wouldn’t be a significant disadvantage, except for code that is already flawed. It is analogous to the argument used for ignoring EINTR, because depending on it for handling signals is inherently racy. |
No consensus was found, I close the issue. |
Should this issue be reopened in light of If .close() shouldn't raise BrokenPipeError in .communicate() (and it |
"Should this issue be reopened in light of http://bugs.python.org/issue26372 (Popen.communicate not ignoring BrokenPipeError)?" I don't like reopen old issues. IMHO the two issues are different enough to justify two entries in the bug tracker. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: