[Python-Dev] EINTR handling...

[Nick Coghlan]

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 ;)

Cheers,
Nick.

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