Socket objects returned by socket.accept() get their blocking and timeout setting(s) from socket.defaulttimeout. This can be in conflict with reality of the (non-)blocking mode of actual OS-level socket they use. For instance, FreeBSD sockets inherit their socket options from the parent socket on accept(2) system call, and thus a socket object with defined socket timeout and default defaulttimeout returns a socket object that seems to be blocking, non-timeout socket, but the underlying OS socket is actually in nonblocking mode, which can cause read/recv and write/send operations to behave unexpectedly. Even worse, POSIX/SUSv3 doesn't explicitly require socket option inheritance (http://www.opengroup.org/onlinepubs/009695399/functions/accept.html). The socket library should explicitly set the socket timeout mode (either to defaulttimeout, or with accompanying documentation, inherit the value from socket object passed to accept()) and modify the OS socket options accordingly.
Logged In: YES user_id=1548868 Making socket objects behave reliably can be achieved simply by always calling internal_setblocking in init_sockobject of socketmodule.c, but this causes overhead of one system call on all socket creations. Alternatively one could call internal_setblocking from sock_accept if parent socket has timeouts/nonblocking mode enabled. This should work in under all reasonable scenanarios and avoid system call overhead on majority of cases.
I am sorry this has not gotten any response. There does not seem to currently be anyone specifically working on the socket module, so this got lost among hundreds of other feature requests.
The problem you have reported here was later independently reported in Issue7995 where a possible fix has been proposed. Suggest adding yourself to the nosy list of that issue to monitor current status.
