[Python-Dev] EINTR handling...

Nick Coghlan ncoghlan at gmail.com
Fri Aug 30 14:13:51 CEST 2013

On 30 August 2013 20:29, Charles-François Natali <cf.natali at 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 ;)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list