STINNER Victor added the comment:
"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.
--
Akira Li added the comment:
Should this issue be reopened in light of
http://bugs.python.org/issue26372 (Popen.communicate not ignoring
BrokenPipeError)?
If .close() shouldn't raise BrokenPipeError in .communicate() (and it
shouldn't) then it seems logical that .close() shouldn't raise
STINNER Victor added the comment:
No consensus was found, I close the issue.
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23570
___
Martin Panter added the comment:
After understanding the Windows test failure in Issue 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
Serhiy Storchaka added the comment:
I don't see a difference between buffered file and Popen object. Both are
useless
after closing, both can raise an exception when flush a buffer on closing. Why
suppress an exception in one case but not in other? I think this question
needs wider
Serhiy Storchaka added the comment:
New patch to fix the bug seen by Serhiy.
I thought about different solution:
try:
if input:
self.stdin.write(input)
finally:
self.stdin.close()
But your approach looks working too,
--
STINNER Victor added the comment:
I thought about different solution:
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.
--
___
Python tracker
Serhiy Storchaka added the comment:
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
BrokenPipeError.
Martin Panter added the comment:
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.
Serhiy Storchaka added the comment:
Do you want to modify IOBase.__exit__ to ignore I/O errors in close()? I think
such changes should be discussed in Python-Dev.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23570
STINNER Victor added the comment:
Do you want to modify IOBase.__exit__ to ignore I/O errors in close()?
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
STINNER Victor added the comment:
New patch to fix the bug seen by Serhiy.
Anyway, we closed all pipes
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
New submission from STINNER Victor:
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
13 matches
Mail list logo
