Subject: Re: [boost] Boost.Process 0.5 released
From: Boris Schaeling (boris_at_[hidden])
Date: 2012-08-22 19:08:21
On Wed, 22 Aug 2012 15:02:08 +0200, Klaim - Joël Lamotte
> I think a first thing would be to decide if child have to stay an id
> instead of the representation of the child process.
> At the moment, the current proposition is a bit unclear on this point. I
> see two solutions:
> 1. change the name of child. Basically, boost::process::child appears to
> me as the representation of a child process.
> If it was child_id, then I wouldn't have made the suggestions I made
> that is..
> 2. make it a real representation of the child process (as suggested
> before) with RAII and calling automatically the wait function on
> destruction if not explicitely detached.
> This is more work obviously and different design than the current
> proposal but at least it would impact only the child type.
I think if CreateProcess() would return eg. only a process ID,
boost::process::child would have been a typedef (as on POSIX we have only
the pid which we get back from fork()). As CreateProcess() returns
PROCESS_INFORMATION which has four member variables, I felt it makes more
sense to wrap the return values in a class. And given that you can copy
the pid on POSIX and PROCESS_INFORMATION on Windows, I didn't really want
to enforce tighter restrictions. Someone who doesn't like this can still
wrap boost::process::child in a non-copyable user defined class? But I'm
not sure whether the library should forbid you to do what you can do with
the native types (and it's not that developers have serious problems with
those copyable native types?).
I wouldn't want to use the child class either if it does something extra
which I don't need. For example, if I don't care about my child processes
and call signal() to ignore SIGCHLD, I don't want the child class to wait
for the child process to exit. While those extra features can be useful, I
think they would need to be provided as opt-ins (like another class
developers have to use explicitly if they don't want to use the
light-weight class child).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk