Charles-Francois Natali <neolo...@free.fr> added the comment: > I don't see any evidence in support of this statement.
>From Microfost Windows' documentation: "The parameter writefds identifies the sockets that are to be checked for writability. If a socket is processing a connect call (nonblocking), a socket is writeable if the connection establishment successfully completes. If the socket is not processing a connect call, writability means a send, sendto, or WSASendto are guaranteed to succeed. However, they can block on a blocking socket if the len parameter exceeds the amount of outgoing system buffer space available. It is not specified how long these guarantees can be assumed to be valid, particularly in a multithreaded environment." For the Linux kernel, a few years ago a socket would be returned as writable if it had a fixed amount of send socket buffer queue available, so if you send more than is available at that time, you're either going to block, or get an error (now the threshold is 1/2 of the used buffer space, but this doesn't change the problem). That's why I said it's not reliable. > Did you notice that the FreeBSD thread you referenced is: * 6 years old * about UDP So ? > It's not obvious to me that it's actually relevant here. I'm not saying that it's the source of the problem, I'm just saying that there's a record of send() calls failing on lack of socket buffers, on blocking sockets. ---------- _______________________________________ 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
