The new std.process is ready for review

[Steven Schveighoffer]

On Tue, 12 Mar 2013 11:02:45 -0400, Vladimir Panteleev  
<vladimir at 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