On 30 August 2013 20:29, Charles-François Natali <cf.nat...@gmail.com> wrote: > 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?
Sounds good to me. I don't believe there's been a conscious decision that we *shouldn't* handle it, it just hasn't annoyed anyone enough for them to propose a systematic fix in CPython. If that latter part is no longer true, great ;) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
