traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Clarify socket timeout behavior vs system network stack behavior on connect 

for issue5293.
This commit is contained in:
Gregory P. Smith 2009-02-18 05:46:11 +00:00
parent 580d7c1f57
commit 8367becc02
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Doc/library/socket.rst
View File

@ -726,12 +726,13 @@ correspond to Unix system calls applicable to sockets.
Some notes on socket blocking and timeouts: A socket object can be in one of
three modes: blocking, non-blocking, or timeout. Sockets are always created in
blocking mode. In blocking mode, operations block until complete. In
blocking mode. In blocking mode, operations block until complete or
the system returns an error (such as connection timed out). In
non-blocking mode, operations fail (with an error that is unfortunately
system-dependent) if they cannot be completed immediately. In timeout mode,
operations fail if they cannot be completed within the timeout specified for the
socket. The :meth:`setblocking` method is simply a shorthand for certain
:meth:`settimeout` calls.
socket or if the system returns an error. The :meth:`setblocking` method is simply
a shorthand for certain :meth:`settimeout` calls.
Timeout mode internally sets the socket in non-blocking mode. The blocking and
timeout modes are shared between file descriptors and socket objects that refer
@ -742,7 +743,9 @@ completed immediately will fail.
Note that the :meth:`connect` operation is subject to the timeout setting, and
in general it is recommended to call :meth:`settimeout` before calling
:meth:`connect`.
:meth:`connect` or pass a timeout parameter to :meth:`create_connection`.
The system network stack may return a connection timeout error
of its own regardless of any python socket timeout setting.
.. method:: socket.setsockopt(level, optname, value)