[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Kristján Valur Jónsson]

Kristján Valur Jónsson <kristjan at ccpgames.com> added the comment:

I can't see how that patch has anything to do with it.  The problem has been present since at least 2.5.  Your patch fixed it for timeout>0.0 but left the 0.0 case still broken.

It comes from these lines in init_sockobject:
{
     s->sock_timeout = defaulttimeout;
     if (defaulttimeout >= 0.0)
         internal_setblocking(s, 0);
}
This code assumes that the socket's internal state is always blocking, and so only switches it into the non-blocking state if required.

Now, you fixed the 'accept' case with your socket.py patch, but you left out the case where accept_socket.gettimeout() == 0.0.  In other words, you fixed only accept_socket.gettimeout() > 0.0

We can fix it to be as advertized, except that the second part is not possible: 
"if the listening socket is in non-blocking mode, whether the socket     returned by accept() is in blocking or non-blocking mode is operating system-dependent. If you want to ensure cross-platform behaviour, it is recommended you manually override this setting."
The reason is that it is impossible to _ask_ the socket whether it is blocking or non-blocking and therefore, accepted_socket.gettimeout() will not be truthful.

imho, we should just simplify this rule and have the accepted socket inherit the accept socket's properties if defaulttimeout() == None, and not make this special case.  I'll prepare a demonstration patch.

I've added a suggested patch.
p.s. My comments about fixing things in socketmodule.c were only half correct.  I didn't realize that accept had been broken into _accept and socket() in py3k.

----------
hgrepos: +14
Added file: http://bugs.python.org/file21490/defined.patch

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