Martin v. Löwis <mar...@v.loewis.de> added the comment: > Here is the issue (put plainly):
Unfortunately, I still don't understand it. I go through your plain elaboration below. > Python sockets support a notion of timeout (note this notion is not > reflected in the OS socket API). Correct. > The python socket implementation of timeouts uses the underlying OS / > socket API to provide this by setting the socket to nonblocking and > setting a timeout value in a Python object that holds socket info. Correct. > This implementation assumes that the OS sets any socket it receives > via accept to nonblocking. (this is a false assumption on BSD) Not true. It doesn't assume that (it doesn't assume the reverse, either). > The end result is that the OS has a nonblocking socket and the Python > object thinks it is blocking. This is why the socket object in > Python has timeout=None yet calling fcntl shows the socket is > nonblocking. That conclusion is flawed. Python has not associated a timeout with the socket. It makes no claims as to whether the socket is blocking or not. So you have created a non-blocking socket without timeout. I cannot see anything wrong with such a thing. The system explicitly supports such sockets (and, as you point out, it doesn't even have the notion of "per-socket timeouts"). And so should Python support them as well. > Calling code paths that handle timeouts and expect the socket to > block causes bugs like I described in my code. This behavior is > clearly wrong under any interpretation! What about my interpretation above? 1 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7995> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com