[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Antoine Pitrou]

On Mon, 01 Sep 2014 19:15:33 +1200
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Victor Stinner wrote:
> > 
> > Le 1 sept. 2014 00:17, "Marko Rauhamaa" <marko at pacujo.net 
> > <mailto:marko at pacujo.net>> a écrit :
> >  > If a signal is received when read() or write() has completed its task
> >  > partially (> 0 bytes), no EINTR is returned but the partial count.
> >  > Obviously, Python should take that possibility into account so that
> >  > raising an exception in the signal handler (as mandated by the PEP)
> >  > doesn't cause the partial result to be lost on os.read() or os.write().
> > 
> > This case is unrelated to the PEP, the PEP only changes the behaviour 
> > when a syscall fails with EINTR.
> 
> I think there's a problem here, though. As thing stand, a
> signal handler that doesn't raise an exception can set a flag,
> and code after the read() can test it.
> 
> Under the proposed scheme, the signal handler has to
> be made to raise an exception so that the read will be
> broken out of in the EINTR case.

The PEP already addresses this remark:

""Applications relying on the fact that system calls are interrupted
with ``InterruptedError`` will hang. The authors of this PEP don't
think that such application exist.

If such applications exist, they are not portable and are subject to
race conditions (deadlock if the signal comes before the system
call)."""

Regards

Antoine.