2013/8/30 Charles-François Natali <cf.natali@gmail.com>
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.

I agree.
Is there a way to see in C code where EINTR is not handled?
Or a method to handle this systematically?
 
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.pythoto see n.org/issue3771


cf
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/amauryfa%40gmail.com



--
Amaury Forgeot d'Arc