Kristján Valur Jónsson <krist...@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 <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
