The new std.process is ready for review

[Lars T. Kyllingstad]

On Wednesday, 6 March 2013 at 16:45:51 UTC, Steven Schveighoffer 
wrote:
> On Tue, 05 Mar 2013 17:38:09 -0500, Vladimir Panteleev 
> <vladimir at thecybershadow.net> wrote:
>
>> By the way, I should mention that I ran into several issues 
>> while trying to come up with the above example. The test 
>> program does not work on Windows, for some reason I get the 
>> exception:
>>
>> std.process2.ProcessException at std\process2.d(494): Failed to 
>> spawn new process (The parameter is incorrect.)
>
> I think Lars is on that.

I'm going to need som help with this one.  I only have Linux on 
my computer, and I can't reproduce the bug in Wine.

As a first step, could someone else try to run Vladimir's test 
case?


>> I've also initially tried writing a different program:
>>
>> [...]
>
> Linux should work here.  From what I can tell, you are doing it 
> right.
>
> If I get some time, I'll try and debug this.

I think I know what the problem is, and it sucks bigtime. :(

Since the child process inherits the parent's open file 
descriptors, both ends of a pipe will be open in the child 
process.  We have separated pipe creation and process creation, 
so spawnProcess() knows nothing about the "other" end of the pipe 
it receives, and is therefore unable to close it.

In this particular case, the problem is that "sort" doesn't do 
anything until it receives EOF on standard input, which never 
happens, because even though the write end of the pipe is closed 
in the parent process, it is still open in the child.

I don't know how to solve this in a good way.  I can think of a 
few alternatives, and they all suck:

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.

Lars