This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kirma
Recipients
Date 2006-07-02.13:05:04
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2008-01-20 09:58:47adminlinkissue1515839 messages
2008-01-20 09:58:47admincreate