fileutils.c must be modified to retry when a function fails with EINTR: see the PEP 475.

I'm working on a patch.

New changeset 0b99d7043a99 by Victor Stinner in branch 'default':
Issue #23694: Enhance _Py_open(), it now raises exceptions
https://hg.python.org/cpython/rev/0b99d7043a99

New changeset cfe541c694f3 by Victor Stinner in branch 'default':
Issue #23694: Enhance _Py_fopen(), it now raises an exception on error
https://hg.python.org/cpython/rev/cfe541c694f3

fileutils_eintr.patch: handle EINTR for open, fopen and dup (only on Linux for dup in _Py_dup).

_Py_wfopen() and _Py_fopen() are not modified because callers are not really prepared to handle exceptions. These functions are mostly used during early steps of Python initializations. If someone is motived, you can propose a patch for these functions.

For other functions (cwd, readlink, etc.), it's not clear to me if we can get EINTR or not.

LGTM.

Note that dup() cannot fail with EINTR, it is non-blocking: dup2() can
fail, because f the target FD is open, it has to close it, but not
dup().

See e.g. this man page from my Debian:
       EINTR  The dup2() or dup3() call was interrupted by a signal;
see signal(7).

Charles-François Natali added the comment:
> Note that dup() cannot fail with EINTR, it is non-blocking: dup2() can
> fail, because f the target FD is open, it has to close it, but not
> dup().

Oh right, I misread the manual page. I will leave _Py_dup() unchanged.
Thanks for the review.

All functions which can fail with EINTR now retries the function on EINTR. I close the issue.

New changeset ed25e945cdc2 by Victor Stinner in branch 'default':
Issue #23694: Handle EINTR in _Py_open() and _Py_fopen_obj()
https://hg.python.org/cpython/rev/ed25e945cdc2

New changeset 2e1234208bab by Victor Stinner in branch 'default':
Issue #23694: Fix usage of _Py_open() in the _posixsubprocess module
https://hg.python.org/cpython/rev/2e1234208bab