[issue10473] Strange behavior for socket.timeout

Ned Deily report at bugs.python.org
Sun Nov 21 02:46:41 CET 2010


Ned Deily <nad at acm.org> added the comment:

There is a difference in behavior in the accept() socket call between Linux and BSD systems (including OS X). As documented in the Debian Linux man page for accept(2):  "On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the listening socket.  This behavior differs from the canonical BSD sockets implementation.   Portable  programs should not rely on inheritance or noninheritance of file status flags and always explicitly set all required flags on the socket returned from accept()."

Calling the settimeout method with a positive, non-zero value causes Modules/setsocketmodule.c to set O_NONBLOCK on the listening socket.  On BSDish systems, the accepted socket for the incoming connection inherits that attribute, which causes the recv(2) socket call to return EAGAIN when the received bytes are consumed rather than block, which causes the socket modules SocketIO.readinto() to return None up the chain, which ultimately causes io.TextIOWrapper.readline() to return all that it has received regardless of whether a newline character was received.

It is for that reason that socket.makefile() is documented: "The socket must be in blocking mode (it can not have a timeout)."  Because of the inheritance behavior, the test case fails to adhere to that.
 
http://docs.python.org/py3k/library/socket.html#socket.socket.makefile

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10473>
_______________________________________


More information about the Python-bugs-list mailing list