The new std.process is ready for review

[Vladimir Panteleev]

On Sunday, 10 March 2013 at 16:04:51 UTC, Marco Leise wrote:
> Am Sat, 09 Mar 2013 13:35:26 -0500
> schrieb "Steven Schveighoffer" <schveiguy at yahoo.com>:
>
>> On Sat, 09 Mar 2013 11:05:14 -0500, Lars T. Kyllingstad  
>> <public at kyllingen.net> wrote:
>> 
>> > 1. Make a "special" spawnProcess() function for pipe 
>> > redirection.
>> > 2. Use the "process object" approach, like Tango and Qt.
>> > 3. After fork(), in the child process, loop over the full 
>> > range of  possible file descriptors and close the ones we 
>> > don't want open.
>> >
>> > The last one would let us keep the current API (and would 
>> > have the added  benefit of cleaning up unused FDs) but I 
>> > have no idea how it would  impact performance.
>> 
>> I think 3 is the correct answer, it is consistent with 
>> Windows, and the  most logical behavior.  For instance, if 
>> other threads are open and doing  other things that aren't 
>> related (like network sockets), those too will be  inherited!  
>> We should close all file descriptors.
>
> So that means on Posix any programming scheme involving
> passing open descriptors on to child processes is not going to
> work with std.process? Not that I know of any, but if that's
> what will happen it is good to know the cost. ;)

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.