Repository navigation
PEP 475: handle EINTR in fileutils.c #67882
Description
| BPO | 23694 |
|---|---|
| Nosy | @vstinner |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2015-03-18.10:08:40.491>
created_at = <Date 2015-03-17.23:19:38.389>
labels = []
title = 'PEP 475: handle EINTR in fileutils.c'
updated_at = <Date 2015-03-30.00:21:08.497>
user = 'https://github.com/vstinner'bugs.python.org fields:
activity = <Date 2015-03-30.00:21:08.497>
actor = 'python-dev'
assignee = 'none'
closed = True
closed_date = <Date 2015-03-18.10:08:40.491>
closer = 'vstinner'
components = []
creation = <Date 2015-03-17.23:19:38.389>
creator = 'vstinner'
dependencies = []
files = ['38535']
hgrepos = []
issue_num = 23694
keywords = ['patch']
message_count = 9.0
messages = ['238358', '238359', '238366', '238367', '238381', '238386', '238396', '238398', '239538']
nosy_count = 3.0
nosy_names = ['vstinner', 'neologix', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue23694'
versions = ['Python 3.5']
Activity
vstinner commentedon Mar 17, 2015
fileutils.c must be modified to retry when a function fails with EINTR: see the PEP-475.
I'm working on a patch.
python-dev commentedon Mar 17, 2015
New changeset 0b99d7043a99 by Victor Stinner in branch 'default':
Issue bpo-23694: Enhance _Py_open(), it now raises exceptions
https://hg.python.org/cpython/rev/0b99d7043a99
python-dev commentedon Mar 18, 2015
New changeset cfe541c694f3 by Victor Stinner in branch 'default':
Issue bpo-23694: Enhance _Py_fopen(), it now raises an exception on error
https://hg.python.org/cpython/rev/cfe541c694f3
vstinner commentedon Mar 18, 2015
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.
neologix commentedon Mar 18, 2015
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).
vstinner commentedon Mar 18, 2015
Charles-François Natali added the comment:
Oh right, I misread the manual page. I will leave _Py_dup() unchanged.
Thanks for the review.
vstinner commentedon Mar 18, 2015
All functions which can fail with EINTR now retries the function on EINTR. I close the issue.
python-dev commentedon Mar 18, 2015
New changeset ed25e945cdc2 by Victor Stinner in branch 'default':
Issue bpo-23694: Handle EINTR in _Py_open() and _Py_fopen_obj()
https://hg.python.org/cpython/rev/ed25e945cdc2
python-dev commentedon Mar 30, 2015
New changeset 2e1234208bab by Victor Stinner in branch 'default':
Issue bpo-23694: Fix usage of _Py_open() in the _posixsubprocess module
https://hg.python.org/cpython/rev/2e1234208bab