The new std.process is ready for review

[Steven Schveighoffer]

On Sun, 10 Mar 2013 13:03:20 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:

> Am Sun, 10 Mar 2013 17:07:26 +0100
> schrieb "Vladimir Panteleev" <vladimir at thecybershadow.net>:
>
>> I think the idea is that if you rely on such platform-specific
>> behavior, you probably shouldn't be using std.process in the
>> first place - as its goal is to provide high-level cross-platform
>> abstractions for the most common operations, rather than try to
>> cover all features exposed by all operating system APIs.

I think we can find a mix.  Since fork gives you a convenient location to  
close all open file descriptors, we should do so by default.  But if you  
want standard posix behavior and you want to rely on F_CLOEXEC, you should  
be able to do that with a flag to spawnProcess.  We already have a Config  
parameter that is already used to control stream closing behavior.  We  
should extend that.

> Not necessarily. Why do you have to deal with this stuff in
> std.process in the first place? Because during development of
> the sockets and file APIs in Phobos noone thought about this
> issue. It should be a Phobos convention that descriptors are
> closed on exec by default and changed in the few places where
> sockets and files are created.

It only becomes a problem for long-living subprograms.  For example, if  
you run an "ls" command as a subprocess, who cares if it keeps open  
sockets for a fraction of a second?  The other real issue is if a child  
process unknowingly keeps its stdin/stderr/stdout open by having the other  
end open (Vladimir's situation).

But it certainly is a problem that we can and should solve.

However, I don't agree with your solution.  We should not be infiltrating  
std.process hacks into all creation of streams.  Not only is that  
difficult to maintain, but it decouples the purpose of code from the  
actual implementation by quite a bit.  A process may never even spawn a  
child process, or it may call functions that create pipes/threads that  
DON'T set F_CLOEXEC.  Maybe the 3rd party library didn't get that memo.

I see no issue with std.process handling the historic flaws in process  
creation, that is where it belongs IMO.  What's nice about it is, with the  
"close all open descriptors" method, it handles all these cases quite  
well.  We should also give the user a "roll your own" option where it  
doesn't close these descriptors for you, you must set F_CLOEXEC manually.

> Someone who uses Posix APIs directly can thus rely on their
> behavior and std.process can stay ignorant to this platform
> difference and avoid ugly hacks.

Both ways are ugly hacks.  I'd rather have the hacks be in one place, and  
not require 3rd party libs to comply.

-Steve