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.)