Re: [boost] Boost.Process 0.5 released

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  
<mjklaim_at_[hidden]> 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

> [...]