[Python-Dev] EINTR handling...

Amaury Forgeot d'Arc amauryfa at gmail.com
Fri Aug 30 14:06:53 CEST 2013

2013/8/30 Charles-François Natali <cf.natali at 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 <http://bugs.python.org/issue3771>
> cf
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130830/db889e26/attachment.html>

More information about the Python-Dev mailing list