This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, libgfortran] PR 67585 Handle EINTR
- From: Mike Stump <mikestump at comcast dot net>
- To: Fritz Reese <fritzoreese at gmail dot com>
- Cc: Janne Blomqvist <blomqvist dot janne at gmail dot com>, FX <fxcoudert at gmail dot com>, Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 7 Oct 2016 12:46:12 -0700
- Subject: Re: [PATCH, libgfortran] PR 67585 Handle EINTR
- Authentication-results: sourceware.org; auth=none
- References: <1475843186-3429-1-git-send-email-blomqvist.janne@gmail.com> <F04C59DD-1F6D-4E26-AC2E-A1981551A555@gmail.com> <CAO9iq9FKUvfRDqpCSLCC0nwA5UcpFX7ocP9NVmMu+YVJx=NHbg@mail.gmail.com> <CAE4aFA=TAzyrPB5rCHEMzkLeSEm1CAPnn10N=yqo_Bd-Kd-vpQ@mail.gmail.com>
On Oct 7, 2016, at 7:50 AM, Fritz Reese <fritzoreese@gmail.com> wrote:
> what if a user wants/expects a system call to be interrupted?
Then it is interrupted.
> With the patch we would always restart the system call even if
No, this is a misunderstanding on your part. The signal is delivered and delivered first then the system call is restarted.
> 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
No, that isn't possible.
> 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.
Yes, it is. signals are delivered first. First in python, and first in C, there is a reason for that.