On Fri, Oct 7, 2016 at 12:09 PM, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > On Fri, Oct 7, 2016 at 5:50 PM, Fritz Reese <fritzore...@gmail.com> wrote: >> On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist >> <blomqvist.ja...@gmail.com> wrote: >>> On Fri, Oct 7, 2016 at 2:41 PM, FX <fxcoud...@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
