[Python-ideas] Introduce BaseTimeoutError
Nathaniel Smith
njs at pobox.com
Sun Apr 2 21:29:31 EDT 2017
On Sun, Apr 2, 2017 at 4:08 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Both are subclasses of OSError but mean different things. TimeoutError
> means that something in 'your system' did not respond. Socket.timeout means
> that a foreign system did not respond. (I am leaving out a local socket
> connection.) The latter can only happen with a socket call with timeouts
> enabled. If it is possible for TimeoutError to also occur with a
> timeout-enabled socket call, then one might very well want to only catch one
> or catch them separately and respond differently.
I don't necessarily disagree with the conclusion, but I'm pretty sure
this is rationale is wrong: connect / recv / etc. can return ETIMEDOUT
if the peer is non-responsive and some internal
operating-system-specific timeout expires (see e.g. [1], or the
TCP_USER_TIMEOUT socket option). So both TimeoutError and
socket.timeout can indicate a non-responsive remote system, and the
actual difference is in who implements the timeout: socket.timeout
means that the timeout implemented by the Python interpreter and
controlled by socket.settimeout() expired; TimeoutError means that the
timeout implemented by the kernel expired.
You can also get TimeoutError in other odd places like the pthread
synchronization functions that take a timeout, or when working with
POSIX message queues for IPC. These do describe stuff that's on the
same system timing out, but since these APIs aren't exposed by Python
I'm not actually sure if it's possible in practice to get a
TimeoutError except with a socket talking to a non-responsive peer.
-n
[1] https://stackoverflow.com/questions/8471577/linux-tcp-connect-failure-with-etimedout
--
Nathaniel J. Smith -- https://vorpus.org
More information about the Python-ideas
mailing list