-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-40423: Optimization: use close_range(2) if available #22651
Conversation
@kevans91: Status check is done, and it's a failure ❌ . |
@gpshead I have removed the automerge in case my previous comment is not something I am missing, feel free to add it back if everything looks ok |
@kevans91: Status check is done, and it's a success ✅ . |
|
@@ -8779,6 +8782,14 @@ void | |||
_Py_closerange(int first, int last) | |||
{ | |||
first = Py_MAX(first, 0); | |||
#ifdef HAVE_CLOSE_RANGE | |||
if (close_range(first, last, 0) == 0 || errno != ENOSYS) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be nicer to cache ENOSYS
the first time we try close_range
and avoid it in future _Py_closerange
calls — assuming this is ever used more than once per process, which might not be true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I implemented such cache in the PEP 446 implementation: remind if a syscall supports atomic "O_CLOEXEC" flag. See for example _Py_open_cloexec_works in Python/fileutils.c.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, I don't think this code path is sensitive enough to really care.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, nice, I hadn't thought of caching that. good idea. (one less failed syscall attempt before the real work likely involving many syscalls gets done in this case; so not a huge deal but still worthwhile)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the subprocess use case, the cache will likely only be first initialized in child processes, each child process has to do the check, and so the cache is useless.
I would mostly benefit to os.closerange().
I'm fine with not adding a cache. I agree that os.closerange() is an uncommon function.
) close_range(2) should be preferred at all times if it's available, otherwise we'll use closefrom(2) if available with a fallback to fdwalk(3) or plain old loop over fd range in order of most efficient to least. [note that this version does check for ENOSYS, but currently ignores all other errors] Automerge-Triggered-By: @pablogsal
) close_range(2) should be preferred at all times if it's available, otherwise we'll use closefrom(2) if available with a fallback to fdwalk(3) or plain old loop over fd range in order of most efficient to least. [note that this version does check for ENOSYS, but currently ignores all other errors] Automerge-Triggered-By: @pablogsal
close_range(2) should be preferred at all times if it's available, otherwise we'll use closefrom(2) if available with a fallback to fdwalk(3) or plain old loop over fd range in order of most efficient to least.
[note that this version does check for ENOSYS, but currently ignores all other errors]
https://bugs.python.org/issue40423
Automerge-Triggered-By: @pablogsal