Antoine Pitrou <pit...@free.fr> added the comment: > """Generally there is no guarantee that a buffered object works > "properly" when the raw IO object raises some exception > intermittently""" > > I disagree. EINTR is a classic case of this and is something that > buffering IO layers deal with all the time. (readline is just one > example of a buffering io layer)
EINTR is a different matter. To handle EINTR in Python, it is enough to call the signal handlers and then retry the system call (that's what is done in SocketIO.readinto, although FileIO doesn't have such logic). Only if the signal handler raises an exception (which it probably shouldn't do, since asynchronous exceptions are very bad) do you abort the operation. You can't apply the same logic to a socket timeout; the timeout is really an error condition and you certainly shouldn't retry the system call (that would defeat the point of using a timeout). So, to handle it in an entirely correct way, you need to add some out-of-band buffering logic where you store the pending raw reads which have been done but could not be returned to the user. That complicates things quite a bit, especially given that it has to be grafted on at least two layers of the IO stack (the raw IO layer, and the buffered IO layer). Ross' patch does it, but incompletely (it lets the user handle the out-of-band data) and only for readline() (while buffered read() would probably need it too). > The normal behavior for code calling readline() on a socket with a > timeout is likely going to be to close it. Anything else does not > make much sense. (someone may try, but really they're writing their > I/O code wrong if they are using a socket timeout a poor form of task > switching ;) That's my opinion too. So, instead, of doing the above surgery inside the IO stack, the SocketIO layer could detect the timeout and disallow further access. What do you think? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7322> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
