Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-11-14 05:19:12

On Nov 8, 2012, at 10:19 AM, Alex Perry <Alex.Perry_at_[hidden]> wrote:

> On 07 November 2012 20:48 Boris Schaeling [mailto:boris_at_[hidden]] wrote :-
> 
>> At this point there is nothing left on my todo list. I got quite a lot of
>> feedback so far and would appreciate if people can look at this new
>> version again. If there are no major shortcomings found, I'll ask for a
>> formal review.
> 
> However one thing that stops your library being a direct replacement of our own stuff (I hesitate to use the word library for it) is the cleaning up of resources on POSIX.
> 
> The problem we have is that not all child processes are equal - some are important and we care about success or otherwise of their operations - others are more throw away.
> 
> I appreciate that the problem here lies in the underlying signal handling on posix and any application of large enough complexity has probably taken some application wide approach to signals and turned them into something slightly saner for use in a C++ world but still ....
> 
> Would it be possible for boost process to provide at least a partial solution to this?
> 
> For example provide a signal handler which can be installed on SIGCHLD which keeps a record of the previous handler and a container of "don't care about" pid's - when this signal is raised iterate through the pids reaping any results (waitpid(*it, &result, WNOHANG) and removing from the list ) - if the signal doesn't appear to come from one of our ignored pid's then call the previous handler if valid.
> 
> Whilst this isn't a difficult handler to write there are probably a few gotcha's with locking and initialisation so would be nice to have a version already rolled in the library and it might make a nice feature for simple usage.
> 
> execute( run_exe("test.exe"), no_wait() );
> 
> or some such  - which could then be x-platform and avoid build-up of zombie processes without having to do :-
> 
> #if defined(BOOST_POSIX_API)
>    signal(SIGCHLD, SIG_IGN);
> #endif
> execute(run_exe("test.exe"));
> 
> as recommended in the documentation (and also would allow other areas of the application to use asio or some such to handle asynchronous results for different children which just ignoring SIGCHLD would break)

If Boost.Process provided a hook for installing a SIGCHLD signal handler, users could choose when and how to install it. For example an overloaded function/ctor can take a boost::function that can be called with Boost.Process' signal handler, leaving it to the caller to register it. That handler, and the boost::function overload can have two forms: one that chains and one that doesn't.

> Since implementation would probably require a static container doing this in a header only library is possibly more hassle than it's worth but just thought I'd ask.

In the spirit of don't pay for what you don't use, the library can be header only unless one uses this particular feature.

___
Rob