[HN Gopher] Subprocess: Don't close all file descriptors by defa...
___________________________________________________________________
Subprocess: Don't close all file descriptors by default
(close_fds=False)
Author : luu
Score : 22 points
Date : 2024-12-25 10:03 UTC (1 days ago)
(HTM) web link (bugs.python.org)
(TXT) w3m dump (bugs.python.org)
| williamjackson wrote:
| https://github.com/python/cpython/issues/86904
| loeg wrote:
| (The comments before 2022 are all the same; the newest comment
| is only on Github.)
| oseityphelysiol wrote:
| Of all the quirks with process spawning in posix keeping file
| descriptors open is the most problematic one I encountered. This
| bit into my ass while implementing a C library to have proper
| process spawning and stdio handling in LUA. I really wish file
| descriptors were non inheritable by default.
| teddyh wrote:
| > _I really wish file descriptors were non inheritable by
| default._
|
| In Python 3.4, they are (released ten years ago).
| int_19h wrote:
| But in POSIX, they are not, so any module implemented in C is
| still potentially problematic.
| teddyh wrote:
| Only if that C-implemented module uses raw C to create file
| descriptors. _And_ if the module has not gotten an update
| in the past _ten years_ to fix the problem.
| htfy96 wrote:
| Meanwhile VSCode's terminal still leaks Electron fds:
| https://github.com/microsoft/node-pty/issues/657
|
| I get this proposal's rationale, but it seems that it would
| implicitly make fd leaks more prone in python programs
| loeg wrote:
| (2020), or perhaps 2021.
| teddyh wrote:
| The counter-arguments presented seem persuasive. This was
| originally submitted in 2020, and closed in 2022. Why is it
| relevant or interesting today?
| mmastrac wrote:
| FDs really should have been opt-in for inheritability from the
| start, with the possible exception of stdio. Inheritability being
| an fcntl is definitely one of the worst bits -- if the APIs for
| fork()/etc were designed today it would probably take a list of
| FDs that would be dup2'd in the new child process.
| stefan_ wrote:
| FDs optin, memory too given the insane performance pitfalls
| architectural issues and pernicious security problems (think
| cloning a CSPRNGs internal state) and suddenly you realize
| CreateProcessA was and always has been the superior API.
| adzm wrote:
| > suddenly you realize CreateProcessA was and always has been
| the superior API
|
| Throw in IOCP and you realize that NT is a pretty solid,
| well-thought-out OS
| loeg wrote:
| > FDs really should have been opt-in for inheritability from
| the start, with the possible exception of stdio.
|
| Yes.
|
| > Inheritability being an fcntl is definitely one of the worst
| bits
|
| Well, or you can use O_CLOEXEC in most APIs that create an fd.
| mmastrac wrote:
| Yep, totally, although there are still some holes in that.
| pipe2 being missing on Darwin is one example. You also need
| to hope that all the libraries you're integrating with are
| using O_CLOEXEC as well.
| nasretdinov wrote:
| Go goes slightly further and opens all descriptors with O_CLOEXEC
| by default, so if you ever execute an external command you have
| to go out of your way to preserve any descriptors, which is
| really nice in my opinion
| loeg wrote:
| Python has done the same thing for the past 10 years for fds
| created by the runtime (Python 3.4). But 3rd party extensions /
| modules may create non-CLOEXEC fds.
| Pesthuf wrote:
| > On macOS, posix_spawn() is even a syscall.
|
| First time I hear about this, interesting. I wonder what the
| performance benefits are like.
| zitterbewegung wrote:
| Dang: Link should be
| https://github.com/python/cpython/issues/86904
___________________________________________________________________
(page generated 2024-12-26 23:01 UTC)