Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Jack Howarth <howarth dot at dot gcc at gmail dot com>]

On Fri, Oct 7, 2016 at 12:09 PM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> 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.
>

One issue that might need to be considered is whether the libgfortran
routines would ever be indirectly called from code that is using
fork()/exec(). We ran into a nasty regression in GNU Make 4.0/4.1
which was tickled when NLS support was enabled which indirectly pulled
in the CoreFoundation framework and its threading support via
libiconv. Upstream fixed this with...

http://savannah.gnu.org/bugs/index.php?46261#comment12

http://git.savannah.gnu.org/cgit/make.git/commit/?id=85c788572d054bc2c41b84007875edbd37ad3ed5

in make 4.2. So using EINTR properly can be really tricky.

>
>
> --
> Janne Blomqvist