On Tue, 12 Mar 2013 11:02:45 -0400, Vladimir Panteleev
<vladi...@thecybershadow.net> wrote:
On Tuesday, 12 March 2013 at 13:56:28 UTC, Steven Schveighoffer wrote:
OK, but it will still solve the specific problem with the other end
being open.
Yes it does. I'd rather solve both, though.
OK. The idea to close all FDs after forking seems to be the best
solution so far, although I have some reservations (scaling for high
max-FD environments, and it doesn't sound like "the right thing to do").
I have those same reservations on scaling. Anecdotal testing shows it
takes about .1 microseconds per call to close on Lars' machine, so it's
likely not terrible.
The "right thing to do" is impossible since the OS doesn't give us the
tools :)
The best interface would be a list of file descriptors to keep open as a
parameter to exec/CreateProcess. That should have been the original
interface on all platforms. Windows ALMOST has this right, as it takes
handles for stdin/stdout/stderr, but it requires that you also inherit all
other inheritable handles in order to do that...
I was thinking that we could implement both approaches (closing all FDs
after forking, and setting FD_CLOEXEC where appropriate), as an escape
hatch: if later we suddenly find out that one of them was a horrible
idea, we can simply remove it without much consequence.
Since all the solutions we are talking about are implementation details,
not specifically requested by the user, it should be easy to switch from
one to the other.
-Steve
