[issue9854] SocketIO should return None on EWOULDBLOCK
Antoine Pitrou pit...@free.fr added the comment: Was committed in r84887. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Antoine Pitrou pit...@free.fr added the comment: Of course, I should have been more clear. What I meant is that there's no such thing as explicit and native as setblocking() for plain files. Indeed. It would probably be a nice addition, assuming it is portable enough. A BlockingIOError is raised if the underlying raw stream is in non blocking-mode, and has no data available at the moment. This is valid for BufferedReader, BufferWriter and BufferIOBase classes in various methods while io.RawIOBase.write() and io.RawIOBase.read() return None instead. Shouldn't they raise BlockingIOError as well? Why do they return None? Well, that's how it was decided when the new IO lib was designed. See http://www.python.org/dev/peps/pep-3116/#non-blocking-i-o (but this says that write() should return 0, while the FileIO implementation returns None; I'd say that for consistency with read() and readinto() returning None is the right thing). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Antoine Pitrou pit...@free.fr added the comment: The problem with RawIOBase.read is fixed in r84814. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Antoine Pitrou pit...@free.fr added the comment: Here is a patch. The tests are only run for unbuffered objects (buffering=0), since the behaviour of buffered objects is driven by BufferedReader and friends, not by the wrapped SocketIO. -- keywords: +patch nosy: +giampaolo.rodola Added file: http://bugs.python.org/file18883/sockio_nonblock.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file18883/sockio_nonblock.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Changes by Antoine Pitrou pit...@free.fr: Added file: http://bugs.python.org/file18884/sockio_nonblock.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Giampaolo Rodola' g.rod...@gmail.com added the comment:
I've never used socket.socket.makefile so I'm not sure, but its documentation
says:
The socket must be in blocking mode (it can not have a timeout).
If the statement is there because EAGAIN/EWOULDBLOCK were originally raised
then it should be removed, otherwise I question whether makefile() is actually
supposed to support non-blocking sockets in the first place.
IMO, I think it's a matter of figuring out whether makefile() should provide a
socket-like behavior or a file like-behavior first.
In the first case I would expect all errors be raised as if I'm dealing with a
common socket, otherwise they should be silenced/handled internally or
makefile() just fail immediately as there's not such thing as non-blocking
files.
Instead, readinto() should detect the blocking condition (EAGAIN /
EWOULDBLOCK) and
return None (same for write(), I imagine).
io.RawIOBase.readinto doc says:
Read up to len(b) bytes into bytearray b and return the number of bytes read.
...so returning 0 instead of None looks more natural to me.
Same for write, also because:
open('xxx', 'w').write('')
0
I've also noticed that socket.SocketIO.readinto has a while loop which
continues in case of EINTR and that's something which should be removed in case
makefile() actually intends to support non-blocking sockets.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9854
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9854] SocketIO should return None on EWOULDBLOCK
Antoine Pitrou pit...@free.fr added the comment: Le mardi 14 septembre 2010 à 23:19 +, Giampaolo Rodola' a écrit : I've never used socket.socket.makefile so I'm not sure, but its documentation says: The socket must be in blocking mode (it can not have a timeout). If the statement is there because EAGAIN/EWOULDBLOCK were originally raised then it should be removed, otherwise I question whether makefile() is actually supposed to support non-blocking sockets in the first place. If it wasn't supposed to, we can add that support. The statement comes from the 2.x doc; 2.x didn't have a notion of non-blocking file-like objects at all, so it makes sense. IMO, I think it's a matter of figuring out whether makefile() should provide a socket-like behavior or a file like-behavior first. Well, since it claims to implement RawIOBase, it should provide a RawIOBase-like behaviour :) (and, in any case, the only use of makefile() is to return something file-like. If you want socket-like behaviour, just use the socket) Returning None is what raw I/O objects are supposed to do when they fail reading or writing even a single byte. It is designed and documented as such. (the readinto() doc you mentioned lacked that precision, but I've just fixed it) The reason None is returned (rather than 0 or b'') is so that the caller can recognize the situation and take appropriate measures. For example, if read() returns None, it means some bytes *may* be following but we'll have to wait (select/poll/...) first; if read() returns 0, conversely, it means we've reached EOF (or, on a socket, that the peer has shutdown its side of the connection). These are two very different situations. [file-like behaviour] otherwise they should be silenced/handled internally or makefile() just fail immediately as there's not such thing as non-blocking files. Non-blocking files exist: import fcntl, os, io r, w = os.pipe() fcntl.fcntl(r, fcntl.F_SETFL, os.O_NONBLOCK) 0 os.read(r, 2) Traceback (most recent call last): File stdin, line 1, in module OSError: [Errno 11] Resource temporarily unavailable (It seems that on regular files O_NONBLOCK may not have an effect; not under Linux anyway) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
