[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

Change by Martin Panter : -- stage: -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

Martin Panter added the comment: I propose to reject this. Close() should always close the underlying file descriptor or socket, even if there is a blocking error or other exception. -- resolution: -> rejected status: open -> pending ___ Python

[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

Martin Panter added the comment: David, what’s your use case for doing non-blocking buffered writing “correctly”? Would you be able to use the context manager functionality? I would have thought you would explicitly call flush() as many times as necessary, but only call close() once when you

[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

eryksun added the comment: I meant that you need a check in buffered_close such as the following: if (res == NULL) { if (PyErr_ExceptionMatches(PyExc_BlockingIOError)) goto end; PyErr_Fetch(, , ); } else Py_DECREF(res); For 2.7 you could create a

[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

eryksun added the comment: Per issue 16597, when an exception occurs in flush(), the file is closed anyway. You'd have to check the exception and only skip to the end for EWOULDBLOCK or EAGAIN. That way you're not introducing a regression for ENOSPC and other exceptions for which retrying

[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

David Beazley added the comment: Please don't make flush() close the file on a BlockingIOError. That would be an unfortunate mistake and make it impossible to implement non-blocking I/O correctly with buffered I/O. -- ___ Python tracker

[issue25476] close() behavior on non-blocking BufferedIO objects with sockets

New submission from David Beazley: First comment: In the I/O library, there is documented behavior for how things work in the presence of non-blocking I/O. For example, read/write methods returning None on raw file objects. Methods on BufferedIO instances raise a BlockingIOError for