On 2012-08-22 01:21, Boris Schaeling wrote:
On Sun, 19 Aug 2012 20:36:38 +0200, Roland Bock <rbock@eudoxos.de> 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