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.
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
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.
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.
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.
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.
Readit News
I get this proposal's rationale, but it seems that it would implicitly make fd leaks more prone in python programs
In Python 3.4, they are (released ten years ago).
Deleted Comment
Throw in IOCP and you realize that NT is a pretty solid, well-thought-out OS
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.
First time I hear about this, interesting. I wonder what the performance benefits are like.