Boost logo

Boost :

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
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.)


Boost list run by bdawes at, gregod at, cpdaniel at, john at