Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Boris Schaeling (boris_at_[hidden])
Date: 2012-08-25 16:37:40

On Wed, 22 Aug 2012 21:14:25 +0200, Alexander Lamaison  
<awl03_at_[hidden]> wrote:

> [...]I'd strongly argue that #ifdef is not the appropriate tool on the
> /client/ side of the library.  After all the entire point of a Boost
> library is to abstract such details away.  Certainly in the common use
> cases.

I'm not necessarily happy about the #ifdefs either. But I don't rule them  
out completely. It all depends on the alternatives. And for the most  
complicated use cases (cleaning up resources and waiting asynchronously  
for processes to exit) we don't have anything else right now? Whatever you  
come up with has to be at least as good as what we have right now. And if  
you look eg. at the example at  
<http://www.highscore.de/boost/process0.5/boost_process/tutorial.html#boost_process.tutorial.cleaning_up_resources>  
I think it will be tough to beat that one in clarity and simplicity.

> [...]I'm not very familiar with POSIX processes.  Is SIGCHLD required for
> *all* process use-cases or just more advanced ones that give you more
> control/introspection than Windows processes?

I think there are basically three scenarios:

- You don't mess around with SIGCHLD at all: Terminated child processes  
must be reaped with a blocking call to wait.
- You call signal(SIGCHLD, SIG_IGN): Terminated child processes are reaped  
automatically (by the kernel).
- You set a signal handler for SIGCHLD: You still must call the blocking  
function wait. But if you do this in the signal handler, wait returns  
immediately (this is the asynchronous waiting model).

As it all works differently on Windows, and as this is not only about  
cleaning up resources but also partly about fetching the status of the  
terminated child process (it is returned by wait), all of this has to be  
considered for a platform-independent solution and weighed against the  
#ifdef alternatives.

> [...]Economy of what?  I'm sure you don't mean performance because  
> blanking
> out the environment on Windows is just a matter of passing L"\0\0" as
> the lpEnvironment paramteter of CreateProcessW.  I'd advocate making
> that the default and setting the parameter to NULL if the caller passes
> inherit_env.  That way you get the same behaviour on both platforms.

If you want to have a certain behavior on all platforms, you only need to  
use an initializer. But if someone else doesn't care about a certain  
behavior, the library shouldn't do something no one asked for. (Not to  
think about what the same behavior should actually be. One could also  
argue that the Windows behavior should be the default. This leads to the  
question how the library user will know and remember what the default is.  
And then there are other settings like for standard streams which I'm  
afraid someone wants then to have equalized next.)

Boris