This is dependent on issue40422; the diff on top of that (PR19075) looks like the attached. Effectively, 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.

PR will be sent after issue40422 is resolved.

for reference, very recent Linux kernels appear to have gained a close_range syscall.  http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html

Your diff isn't quite sufficient as is.  When depending on a syscall that has a function provided by libc, the libc function may exist (thus HAVE_CLOSE_RANGE will be true at Python compile time) but the system the process is running on may not support the system call.  So it'll return an EINVAL (or something like that) error.

Special handling of that error to add an `else {...}` falling back to the other codepath is necessary.

Ah, I will fix this and then submit a PR, thanks... hopefully it returns ENOSYS.

Ah, yeah ENOSYS is it.  I had to do this trick in older subprocess versions for something else.  Still visible here in the old 2.7 backport: https://github.com/google/python-subprocess32/blob/main/_posixsubprocess.c#L801

New changeset 1800c600801709958af66bebfa683a4e7570810f by Kyle Evans in branch 'master':
bpo-40423: Optimization: use close_range(2) if available (GH-22651)
https://github.com/python/cpython/commit/1800c600801709958af66bebfa683a4e7570810f

thanks Kyle!