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 > <hst...@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.
