[PATCH, libgfortran] PR 67585 Handle EINTR

Fritz Reese fritzoreese@gmail.com
Fri Oct 7 14:50:00 GMT 2016


On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> On Fri, Oct 7, 2016 at 2:41 PM, FX <fxcoudert@gmail.com> wrote:
>>> Many POSIX systems have the bad habit of not restarting interrupted
>>> syscalls. On these systems it's up to the user to check for an error
>>> with errno == EINTR and restart manually. This patch does this for
>>> libgfortran, so that GFortran users don't have to do it.
>>
>> I have not much experience with EINTR, but is it garanteed that those EINTR loops will never cycle forever?
>
> Hmm, no I don't think so, but I don't think it'll be a problem. So on
> systems where syscalls are not restarted automatically, EINTR happens
> when the process receives a signal while blocked in a system call [1].
> So I suppose in theory you could have a situation where something
> continuously fires signals at the process, and the result is some kind
> of race between the process restarting the syscall which then never
> manages to complete before being interrupted again. But I think this
> goes into the "Doctor, this hurts! Then don't do that" territory.
>
> There's some more info in https://www.python.org/dev/peps/pep-0475/
> (Python nowadays does the same as this patch).


Just one concern (slightly different from the race you described) -
what if a user wants/expects a system call to be interrupted? With the
patch we would always restart the system call even if the user was
expecting it would be interrupted. For small calls like lseek this may
not be a big deal but if read on a pipe/socket/terminal is restarted
after being interrupted (e.g. with CTRL-C) we may loop forever even if
the user program was written to expect and handle EINTR after the read
call, e.g. to terminate nicely with "non async-safe" calls like printf
that couldn't be done in the handler.

This is discussed as "use case 2" in the PEP you referenced. Python
handles this case by explicitly calling user defined signal handlers
directly after EINTR and checking the return value from the handler,
only trying again if the handler reports success. Not so simple I
think with libgfortran.

---
Fritz Reese



More information about the Gcc-patches mailing list