[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