Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Roland Bock (rbock_at_[hidden])
Date: 2012-08-22 01:26:06

On 2012-08-22 01:21, Boris Schaeling wrote:
> On Sun, 19 Aug 2012 20:36:38 +0200, Roland Bock <rbock_at_[hidden]> wrote:
>
>> [...]
>>> Something like (assuming the design I suggested and assuming the
>>> cleanup
>>> would be optional- would it be?):
>>>
>>> child_process cp( cmd_line("test --foo /bar"), auto_cleanup() );
>>>
>>> The work would then be done in the constructor with posix
>>> implementation,
>>> in destructor in windows.
>> Calling the signal function in the constructor might be a bit strange
>> since it sets the signal handler for SIGCHLD in general, not just for
>> this specific child process. That's why I suggested a method that sets
>
> Yes, Roland highlights a problem with signals. As signal handlers are
> set globally in an application, libraries can't assume they can do
> what they want. So I rather let the application developer handle
> signals explicitly - he is the only one who can do it right. It's a
> pity as that means you have to deal with a platform-specific concept
> (and maybe even code). But then I personally think it's not a big
> problem. It's just a matter of fact that platforms can be
> unfortunately very different.
>
> Boris
>
Still, as mentioned in a later mail, I think that Joel was actually
right with his idea to call signal in the constructor of a not so
lightweight child (is that a fat child? sounds politically incorrect)
because almost everybody will have to do it anyway. Hence my suggestion:

Have a lightweight child class as is for those 5% who need that extra
bit flexibility.
Offer a RAII child that performs signal and discard on its own for 95%
of the users.

Percentages are just a guess, of course :-)

Regards,

Roland