Guido van Rossum wrote Instead, we decided to fix the standard library to always check the return value of send(). Can you help? (If you check in a fix to the 2.1 maintenance branch, you can mark it as "propagate to trunk please".)
Will do - I plan to check in a bunch of fixes tomorrow morning. (continuing gdb hell today). One to consider is the status of 'socket.py' - patched, or not patched...? -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
I'm planning to add a sendall() method to the socket object. See the SF patch: http://sf.net/tracker/index.php?func=detail&aid=474307&group_id=5470&atid=305470 If you have an objection, please let me know. I think this is important enough to bypass the feature freeze -- it's the best way to fix the very real bug (on FreeBSD) of unchecked send() calls. (The alternative would be to add a loop to every use of send().) The sendall() call allows us to fix the standard library modules that currently don't check for send()'s return value, without breaking any existing code, by changing sock.send(data) into sock.sendall(data). Other alternatives intended to fix the problem of unchecked send() calls in standard library module without having to change all send() calls were deemed to dangerous (see the SF patch discussion). I think Anthony is going to add this to the 2.1.2 bugfix release as well -- with the same argument for breaking the feature freeze. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
I'm planning to add a sendall() method to the socket object. See the SF patch:
http://sf.net/tracker/index.php?func=detail&aid=474307&group_id=5 470&atid=305470
If you have an objection, please let me know. I think this is important enough to bypass the feature freeze
The bonehead who uses sendall with a non-blocking socket will, of course, get an EWOULDBLOCK (or platform equivalent) on an oversize send. Maybe EWOULDBLOCK should get turned into ButtHeadProgrammerError("Don't use sendall with a non-blocking socket")? [I agree that this is the best way to fix the std lib, and that it is very important that it be fixed.] - Gordon
The bonehead who uses sendall with a non-blocking socket will, of course, get an EWOULDBLOCK (or platform equivalent) on an oversize send. Maybe EWOULDBLOCK should get turned into ButtHeadProgrammerError("Don't use sendall with a non-blocking socket")?
I think natural selection will take care of this breed. :-)
[I agree that this is the best way to fix the std lib, and that it is very important that it be fixed.]
Thanks! --Guido van Rossum (home page: http://www.python.org/~guido/)
If we're making the std library routines that use sockets robust, I expect we ought to think about exceptions that should be dealt with. My Linux man page suggests that ENOBUFS and EINTR are errors that indicate "try again." There are probably other such errors on other platforms. We use Python sockets and asyncore in ZEO (a Zope subsystem) and I've found that every weird error that I've never heard of seems to occur in the wild. If we don't deal with these errors, then we've haven't fully succeeded in making the calls robust. Jeremy
If we're making the std library routines that use sockets robust, I expect we ought to think about exceptions that should be dealt with. My Linux man page suggests that ENOBUFS and EINTR are errors that indicate "try again." There are probably other such errors on other platforms.
We use Python sockets and asyncore in ZEO (a Zope subsystem) and I've found that every weird error that I've never heard of seems to occur in the wild. If we don't deal with these errors, then we've haven't fully succeeded in making the calls robust.
There's a difference though. The bug I'm trying to fix with sendall() was a silent failure, causing at best protocol failures later, at worst silently lost data. ENOBUFS or EINTR etc. cause clear exceptions when they happen. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Anthony Baxter -
Gordon McMillan -
Guido van Rossum -
Jeremy Hylton