Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Fri, Oct 7, 2016 at 5:50 PM, Fritz Reese <fritzoreese@gmail.com> wrote:
> 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.

Concievable yes, but IMHO unlikely. And since many systems
automatically restart syscalls, a program like the above perhaps isn't
that robust to begin with?

> 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.

With GFortran, a problem is that due to the buffering, handling of
record markers etc. there is no 1:1 mapping between Fortran READ/WRITE
statements and read(2)/write(2) syscalls. So even if we let EINTR
propagate all the way back up to the Fortran caller (as happens now,
except for write()), it actually has no way of knowing what should be
restarted.



-- 
Janne Blomqvist