Skip to content

bpo-40423: Optimization: use close_range(2) if available #22651

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.

Sign up for GitHub

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

Merged
miss-islington merged 4 commits into from
Oct 11, 2020
Merged

bpo-40423: Optimization: use close_range(2) if available #22651

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a2b6c30
configure: start checking for close_range
kevans91 Apr 27, 2020
fd8a008
_Py_closerange: add close_range(2) support
kevans91 Apr 28, 2020
3081c11
📜🤖 Added by blurb_it.
blurb-it[bot] Oct 11, 2020
e1dc819
_Py_closerange: last-minute braino, flip logic around
kevans91 Oct 11, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
_Py_closerange: last-minute braino, flip logic around
  • Loading branch information
@kevans91
kevans91 committed Oct 11, 2020
commit e1dc81975c036b622384e33ae4df0f41eb1bf193
2 changes: 1 addition & 1 deletion Modules/posixmodule.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8783,7 +8783,7 @@ _Py_closerange(int first, int last)
{
first = Py_MAX(first, 0);
#ifdef HAVE_CLOSE_RANGE
if (close_range(first, last, 0) == -1 && errno != ENOSYS) {
if (close_range(first, last, 0) == 0 || errno != ENOSYS) {
Copy link

@cemeyer cemeyer Oct 11, 2020

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.

Copy link
Member

@vstinner vstinner Oct 11, 2020

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.

Copy link
Member

@pablogsal pablogsal Oct 11, 2020

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.

Copy link
Member

@gpshead gpshead Oct 11, 2020

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)

Copy link
Member

@vstinner vstinner Oct 11, 2020

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.

/* Any errors encountered while closing file descriptors are ignored;
* ENOSYS means no kernel support, though,
* so we'll fallback to the other methods. */
Expand Down