The new std.process is ready for review

[Steven Schveighoffer]

On Tue, 12 Mar 2013 16:23:33 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:

> Exactly! And the thousands of bug reports (literally!) in other
> software seem to indicate that an uninstructed human being
> assumes that files don't remain open in sub-processes. We
> aren't even talking about fork here, but really new processes
> created with the exec family of calls.

Given how awesome spawnProcess is, those problems should be very rare, who  
would use fork and exec? :)

> Also common logic suggests that this behavior would not make
> sense, since what can a sub-process do with open files when I
> didn't give it the descriptor numbers?

On unix at least, there can be an agreement that certain descriptors are  
passed as certain numbers.  The code that runs between fork and exec does  
the plumbing.

We already have agreement on what 0, 1, and 2 are.

However, I will agree that this is NOT a common thing to do.  I also agree  
that logic (and practicality) suggests the default on Unix should have  
been to not inherit descriptors.  In fact, you shouldn't really unset the  
close on exec flag except after calling fork to avoid racing with other  
threads that may be calling fork/exec at the same time.

>> Linux file descriptors are integers.  Not quite that hard to pass  
>> another
>> file descriptor via number 3 or 4 for example.
>
> No, but at that point you no longer ignorant about leaking
> descriptors, check what the Phobos file abstraction layer does
> and can unset FD_CLOEXEC:

Yeah, but why were we talking about unintended leaking?  I thought we were  
talking about intended leaking, and you were saying you can't use the  
inherited descriptors:

"Secondly, unless you do a pure fork(), you wont have the data
structures (like File, Socket) available any more in the
sub-process to actually use the inherited file descriptors."

I was contending it was quite possible to intentionally pass the  
descriptors as certain numbers to the child process, and then re-wrap them  
in new File objects.

>
> int fileno = file.fileno();
> int fdflags = fcntl(fileno, F_GETFD);
> fcntl(fileno, F_SETFD, fdflags & ~FD_CLOEXEC);

We actually need to do this in order to properly pass the standard handles.

>> This is not a good position to have as the should-be-agnostic standard
>> library.  Phobos should make the most useful/common/safe idioms the
>> default, but make the non-safe ones possible.  The idea of marking all
>> descriptors as close on exec puts unnecessary burden on those who want  
>> to
>> use straight fork/exec and want to pass Phobos-created descriptors.
>
> We agree on the "possible" and also on the most
> "useful/common/safe" aspect. But the conclusions that we draw
> are different. To you (as I read it) Phobos offers
> functionality to create Posix file descriptors, to me it only
> creates file abstractions that encapsulate and level OS quirks.
>
> It looks to me like the issue was just not considered when
> writing Phobos and we can do it like Ruby and add that
> property to files that allows them to stay open in
> sub-processes. But this should not be a Posix only option.
> SetFileSecurity should do the job on Windows just as well.

Having a property to fetch and set inheritance certainly would be a good  
addition to Phobos.  I still think we should do what the OS specifies by  
default.  There is no real "right" answer there.

-Steve