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: Alex Perry (Alex.Perry_at_[hidden])
Date: 2012-11-08 10:19:14

On 07 November 2012 20:48 Boris Schaeling [mailto:boris_at_[hidden]] wrote :-

> I've uploaded a new version of Boost.Process 0.5 to
> <http://www.highscore.de/boost/process0.5/>:
>
...
 
> 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.
Just took a quick look (scan of the documentation rather than trying anything) and it certainly looks much cleaner and better featured than our roll-your-own x-platform process handling that we use internally.

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)

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.

Alex