On Wed, 22 Aug 2012 15:02:08 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
I think a first thing would be to decide if child have to stay an id value 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). Boris
[...]