The new std.process is ready for review

[Steven Schveighoffer]

On Tue, 12 Mar 2013 13:48:04 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:

> Am Tue, 12 Mar 2013 11:38:35 -0400
> schrieb "Steven Schveighoffer" <schveiguy at yahoo.com>:
>
>> On Tue, 12 Mar 2013 11:24:19 -0400, Vladimir Panteleev
>> <vladimir at thecybershadow.net> wrote:
>>
>> > What I'm worried about is what we can't predict: unexpected side
>> > effects. Disabling one approach should have a less drastic impact than
>> > replacing it with another.
>>
>> If someone depends on the side effects of one approach, it won't matter
>> how less drastic it is, for them it will be bad if we disable it :)
>>
>> I think it's reasonable to expect phobos does what the normal OS  
>> functions
>> do.  If we add the F_CLOEXEC to open pipes or other file descriptors,  
>> then
>> we could never disable that, as people may depend on that.  As our  
>> current
>> code does NOT do that, we also may break code simply by adding that  
>> flag.
>>
>> -Steve
>
> What makes you think Phobos should carry on all the OS
> specific quirks? I think a cross-platform library should
> offer the same behavior on all systems. In this case it can
> also be seen as covering up for an arguably bad Posix API
> design.

D's design should not preclude what is possible.  Someone may have a good  
reason to use that bad API.

What I want to avoid is having to require the user to pay attention to  
handle inheritance if he doesn't care, but also I don't want Phobos to  
puke when you decide to (or have to) circumvent phobos when creating file  
descriptors.

The most robust method is to close all the descriptors we don't want to  
pass, regardless of how they are opened/configured.

> 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.

Linux file descriptors are integers.  Not quite that hard to pass another  
file descriptor via number 3 or 4 for example.

Windows handles (I think) are guaranteed to be the same value in the child  
process.  But they aren't sequential integers starting at 0, so you would  
have to pass somehow, perhaps via parameters, what the handle values are.

I argued early on that the handles to spawnProcess should be unbuffered  
because the buffer will not be passed.  This can result in very weird  
output if both parent and child keep the same handle open.  But File is  
the standard structure for Phobos, so that was used.

> But even if it breaks code, the affected developers will
> hopefully understand that the default of not inheriting
> descriptors by default is safer on the long run.

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.   
Having spawnProcess depend on those flag settings puts unnecessary burden  
on people who use non-phobos calls to open file descriptors and want to  
use spawnProcess.  I'd rather avoid that.

Both methods are very similar, I just feel calling close on all  
descriptors between fork and exec is more effective, and puts the burden  
on spawnProcess instead of the user or other parts of Phobos.

-Steve