This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients exarkun, mdcowles, neologix
Date 2010-04-26.09:22:43
SpamBayes Score 1.1808983e-06
Marked as misclassified No
Message-id <1272273766.84.0.637958196032.issue8493@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 ?
History
Date User Action Args
2010-04-26 09:22:47neologixsetrecipients: + neologix, mdcowles, exarkun
2010-04-26 09:22:46neologixsetmessageid: <1272273766.84.0.637958196032.issue8493@psf.upfronthosting.co.za>
2010-04-26 09:22:45neologixlinkissue8493 messages
2010-04-26 09:22:43neologixcreate