Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-02-10 14:06:35

On 02/10/2011 08:29 AM, Oliver Kowalke wrote:
> Am 10.02.2011 17:11, schrieb Artyom:
>> Small notes:
>>
>> 1. waitpid should be done for specific pid I waiting for
>> to allow other threads to use wait
>> 2. You need to use WNOHANG so it would not be blocking,
>> and allow to check specific ids.
>
> You would create for each child process you want to wait for a separat
> thread? Wouldn't this degrade the performance of the system if you have
> to wait for many processes? Why not using only one thread which handles
> SIGCHLD and catches all child stati?

This is ultimately the best (and only reasonable) approach (where the 
use of a dedicated thread, as opposed to no additional threads and just 
letting the signal handler be called in an arbitrary thread, would be 
optional).  However, it does place a high burden on Boost.Process: since 
under this method Boost.Process will need exclusive control over SIGCHLD 
and all waiting on child processes, it must provide appropriate 
interfaces to interoperate will all other application and library code 
that may wish to deal with child processes.  I believe it should be 
possible to make Boost.Process itself not depend on a dedicated signal 
handling thread, but potentially other application/library code that 
wants to deal with child proceses/sigchld might need the signal handler 
to run in a dedicated thread.  (And potentially, the application or some 
other library may wish to handle SIGCHLD and call wait directly, in 
which case there should be some interface by which this code can notify 
boost.process appropriately.)