On Oct 7, 2016, at 7:50 AM, Fritz Reese <fritzore...@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.
