[Python-Dev] EINTR handling...

Charles-François Natali cf.natali at gmail.com
Fri Aug 30 12:29:12 CEST 2013


Hello,

This has been bothering me for years: why don't we properly handle
EINTR, by running registered signal handlers and restarting the
interrupted syscall (or eventually returning early e.g. for sleep)?

EINTR is really a nuisance, and exposing it to Python code is just pointless.

Now some people might argue that some code relies on EINTR to
interrupt a syscall on purpose, but I don't really buy it: it's highly
non-portable (depends on the syscall, SA_RESTART flag...) and subject
to race conditions (it it comes before the syscall or if you get a
partial read/write you'll deadlock).

Furthermore, the stdlib code base is not consistent: some code paths
handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does
but not sock_send()...
Just grep for EINTR and InterruptedError and you'll be amazed.

GHC, the JVM and probably other platforms handle EINTR, maybe it's
time for us too?

Just for reference, here are some issues due to EINTR popping up:
http://bugs.python.org/issue17097
http://bugs.python.org/issue12268
http://bugs.python.org/issue9867
http://bugs.python.org/issue7978
http://bugs.python.org/issue12493
http://bugs.python.org/issue3771


cf


More information about the Python-Dev mailing list