bpo-40422: create a common _Py_closerange API #19754
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). CLA MissingOur records indicate the following people have not signed the CLA: For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. If you have recently signed the CLA, please wait at least one business day You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
In a later commit, subprocess will be modified to use this instead of hand-rolling it.
_Py_closerange will be more efficient than what was done before in many cases, as it includes the logic to use fdwalk(3) if available that _close_fds_by_brute_force didn't previously have. It will also oftentimes be more efficient as _Py_closerange will later be enhanced to use close_range(2) if it's available.
|
Anything I can do to help this along? Also, not sure if this is is necessarily worth adding a news entry, but I can do that if requested. |
|
Ping... same question as last time, anything I can do to help this along? |
There was a problem hiding this comment.
thanks!
FYI - Linux appears to be gaining a close_range system call this year but writing the code to determine if that syscall is available on the running kernel and use it belongs in a separate PR.
http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html
Indeed, thanks for taking a look! I actually have a branch queued up with the rest in the pipeline that was awaiting this review -- I've split it up into configure script change and then preferring it in _Py_closerange: https://github.com/kevans91/cpython/commits/close_range |
|
@kevans91: Status check is done, and it's a success ✅ . |
Such an API can be used both for os.closerange and subprocess. For the latter, this yields potential improvement for platforms that have fdwalk but wouldn't have used it there. This will prove even more beneficial later for platforms that have close_range(2), as the new API will prefer that over all else if it's available. The new API is structured to look more like close_range(2), closing from [start, end] rather than the [low, high) of os.closerange(). Automerge-Triggered-By: @gpshead
Such an API can be used both for os.closerange and subprocess. For the latter, this yields potential improvement for platforms that have fdwalk but wouldn't have used it there. This will prove even more beneficial later for platforms that have close_range(2), as the new API will prefer that over all else if it's available. The new API is structured to look more like close_range(2), closing from [start, end] rather than the [low, high) of os.closerange(). Automerge-Triggered-By: @gpshead
Such an API can be used both for os.closerange and subprocess. For the latter, this yields potential improvement for platforms that have fdwalk but wouldn't have used it there. This will prove even more beneficial later for platforms that have close_range(2), as the new API will prefer that over all else if it's available.
The new API is structured to look more like close_range(2), closing from [start, end] rather than the [low, high) of os.closerange().
https://bugs.python.org/issue40422
Automerge-Triggered-By: @gpshead