The new std.process is ready for review

[Marco Leise]

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.

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

-- 
Marco