Python also has a PEP to hide EINTR from the user. I suggest we do the
same: retry on a specific list of syscalls, with the exception of
close() and dup2(). The assumption here is Python people did their
homework well before finalizing that PEP and we could just take
advantage of that work.

https://www.python.org/dev/peps/pep-0475/#modified-functions

Not sure if other languages do something similar. Maybe worth
researching a bit too.

On Sun, Jul 21, 2019 at 7:11 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> Thanks for the LWN link. That site is always informative.
>
> Even the verbose solution pasted into my last mail is subtly wrong. From
> the blog comments:
>
> "So, the problem is that close() can actually return interesting return
> values other than 0. AFS, for instance, doesn't write to your networked
> file until you close it, so your quota might have been filled
> meanwhile... so it can return ENOSPC, and not checking for ENOSPC on
> close() can cause data loss. You actually want to see this error, which
> is why "if the close returned EINTR, assume it was okay if the fd no
> longer exists" doesn't work."
>
> It would appear that there's no way to write reliable userland programs
> if the kernel can interrupt close(). And there is so much code that just
> does close() without even checking its return value. I've rarely checked
> it myself. That LWN article has a telling quote: "At one time many years
> ago there was a path in the kernel that returned an error from close and
> it broke so many things. Even emacs crashed."
--
Duy