The new std.process is ready for review

[Jakob Bornecrantz]

On Saturday, 23 February 2013 at 22:48:04 UTC, H. S. Teoh wrote:
> On Sat, Feb 23, 2013 at 03:15:26PM -0500, Steven Schveighoffer 
> wrote:
>> On Sat, 23 Feb 2013 11:42:26 -0500, H. S. Teoh
>> <hsteoh at quickfur.ath.cx> wrote:
>> 
>> >- wait():
>> >   - Some code examples would be nice.
>> >
>> >   - For the POSIX-specific version, I thought the Posix
>> >     standard specifies that the actual return code /
>> >     signal number should be extracted by means of
>> >     system-specific macros (in C anyway)?
>> >     Wouldn't it be better to encapsulate this in a POD
>> >     struct or something instead of exposing the
>> >     implementation-specific values to the user?
>> 
>> We handle the extraction as an implementation detail, the 
>> result should be cross-platform (at least on signal-using
>> platforms). I don't know what a POD struct would get you,
>> maybe you could elaborate what you mean?
>
> Oh, I thought the return value was just straight from the 
> syscall, which requires WIFEXITED, WEXITSTATUS, WCOREDUMP,
> etc., to interpret. If it has already been suitably interpreted
> in std.process, then I guess it's OK.
>
> Otherwise, I was thinking of encapsulating these macros in
> some kind of POD struct, that provides methods like
> .ifExited, .exitStatus, .coreDump, etc. so that the user
> code doesn't have to directly play with the exact values 
> returned by the specific OS.
>
>> >   - How do I wait for *any* child process to terminate, not
>> >     just a specific Pid?
>> 
>> I don't think we have a method to do that.  It would be 
>> complex, especially if posix wait() returned a pid that we
>> are not handling!
>> 
>> I suppose what you could do is call posix wait (I have a 
>> feeling we may need to change our global wait function, or
>> eliminate it), and then map the result back to a Pid you
>> are tracking.
>> 
>> You have any ideas how this could be implemented?  I'd prefer 
>> not to keep a global cache of child process objects...

Btw on windows a simple array with the hProcesses is all you
need to do this, the code below uses AA for reverse lookup,
really simple stuff;

https://github.com/Wallbraker/Unicorn/blob/master/src/uni/util/cmd.d#L354

The code was written before before I know of the new
std.process, but it solved exactly this problem.

>
> Why not?  On Posix at least, you get SIGCHLD, etc., for all 
> child processes anyway, so a global cache doesn't seem to be 
> out-of-place.
>
> But you do have a point about pids that we aren't managing, 
> e.g. if the user code is doing some fork()s on its own. But
> the way I see it, std.process is supposed to alleviate the
> need to do such things directly, so in my mind, if everything
> is going through std.process anyway, might as well just manage
> all child processes there. OTOH, this may cause problems if the
> D program links in C/C++ libraries that manage their own chil
> processes.

But as you state above, it only works for a single CmdGroup on
posix and will probably interact badly with code using wait.

I never got so far because the code works for my limited case,
but supposedly process groups might help out, but the seem to
interfere with signals. More reading is required.

http://linux.die.net/man/7/credentials

>
> Still, it would be nice to have some way of waiting for a set 
> of child Pids, not just a single one. It would be a pain if
> user code had to manually manage child processes all the time
> when there's more than one of them running at a time.
>
> Hmm. The more I think about it, the more it makes sense to just 
> have std.process manage all child process related stuff. It's
> too painful to deal with multiple child processes otherwise.
> Maybe provide an opt-out in case you need to link in some
> C/C++ libraries that need their own child process handling, but
> the default, IMO, should be to manage everything through
> std.process.

This needs to be opt-in, because this stuff should not break
libraries using fork/wait by default.

Cheers, Jakob.