2013/8/30 Charles-François Natali <cf.nat...@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@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
_______________________________________________ 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/archive%40mail-archive.com
