The new std.process is ready for review

[H. S. Teoh]

On Sat, Feb 23, 2013 at 06:55:19PM -0500, Steven Schveighoffer wrote:
> On Sat, 23 Feb 2013 17:46:04 -0500, H. S. Teoh
> <hsteoh at quickfur.ath.cx> wrote:
> 
> >On Sat, Feb 23, 2013 at 03:15:26PM -0500, Steven Schveighoffer wrote:
[...]
> All we look at is WIFEXITED and WIFSIGNALED.  I think the others are
> Linux specific.  I don't think std.process2 should expose all the
> vagaries of the OS it's on, this is a cross-platform library.  Doing
> signals was easy because we embedded it in the int.

Fair enough, I think WIFEXITED and WIFSIGNALED probably covers 99.5% of
the common use cases anyway, so it's probably not worth sweating over.

BTW, is "std.process2" just the temporary name, or are we seriously
going to put in a "std.process2" into Phobos? I'm hoping the former, as
the latter is unforgivably ugly.


> There is always pid.osHandle, which you can use to do whatever you want.

True.


> >>>   - 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!
[...]
> >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.
> 
> I can imagine that a ProcessManager singleton class could be written
> that collects all exited children, and does anything you need.  But I
> don't know if it's a necessary component for std.process to go out the
> door.  We currently have no such feature, so I would push for
> std.process to be reviewed and accepted without that, and then
> consider that an enhancement request.
[...]

Fair enough, we do want the new std.process to get in ASAP.


> Now, one thing we could probably do quickly and easily is add a wait
> function that returns immediately if the process is not done.  I'm
> pretty sure that is supported on all platforms.
[...]

Excellent! I think if we had this, it would address most of my concerns
above.  A non-blocking wait would allow user code to do things like
monitor the progress of child processes, etc., and basically implement
whatever OS-specific stuff it may need to, without adding too much
complication into std.process. I vote for putting this in, and just
leave the handling of multiple child processes to user code.


T

-- 
What are you when you run out of Monet? Baroque.