Charles-Francois Natali <neolo...@free.fr> added the comment: > That's what I thought at first too. But the user's sockets were set to > blocking.
That's one broken networking stack... > In fact, I think it's a little silly that OS X raises the error rather than > just saying that 0 bytes were sent (which is what I suppose that other OSes > do). "Normal" OS just block inside the send() call whenever socket buffers are full (unless there're set to non-blocking). So you can resume sending as soon as buffer space is available, and you don't have to resort to this send()/fail/sleep/re-send() scheme... > But I think it's also not ideal that Python's socket.sendall() can't be used > with confidence under OS X because it can fail under pretty normal > circumstances. Agreed, but it's really a OS X issue here. How would you circumvent this problem anyway ? Add a timeout option to sendall() as a hint to how much we should wait before retrying when errno 35 is returned ? It would be really hacky... Maybe the user could try increasing SO_SNDBUF, but this won't necessarily solve his problem... @exarkun: ideas on this ? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8493> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
