The new std.process is ready for review

[Lars T. Kyllingstad]

On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. 
Kyllingstad wrote:
> It's been years in the coming, but we finally got it done. :)  
> The upshot is that the module has actually seen active use over 
> those years, both by yours truly and others, so hopefully the 
> worst wrinkles are already ironed out.
>
> Pull request:
> https://github.com/D-Programming-Language/phobos/pull/1151
>
> Code:
> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>
> Documentation:
> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>
> I hope we can get it reviewed in time for the next release.  
> (The wiki page indicates that both std.benchmark and std.uni 
> are currently being reviewed, but I fail to find any "official" 
> review threads on the forum.  Is the wiki just out of date?)


Ok, there have been several posts about changes and additions to 
wait(), and I believe Steve has answered them all, so let me just 
summarise:


Non-blocking wait:

This is a good idea, and it should be simple to implement.  I'll 
do that.


Wait for all processes:

This would certainly be convenient, and it is simple to 
implement.  It would require a static __gshared Pid[int] of all 
processes created by spawnProcess(), and we'd simply call wait() 
on all of those.

The question, is this simple enough that we can just leave it to 
the user, thereby avoiding the need for a global Pid cache?  (I 
think so.)

Note that Windows has built-in functionality for waiting for a 
set of processes, namely WaitForMultipleObjects().  std.process2 
would take advantage of that as a minor optimisation, but my 
guess is that the benefit would be negligible.


Wait for any process:

This one is a problem.  POSIX supports it natively, but as has 
been pointed out by others, it would necessarily also affect 
processes *not* created through std.process.  I don't see any 
obvious solution to this.

On Windows, this is also supported through 
WaitForMultipleObjects(), but again, it would require a global 
Pid cache.

I think this one is a no-go.

Lars