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

Subject: Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-02-15 13:10:37

On 02/14/2011 11:12 PM, Oliver Kowalke wrote:
>
>> Arguably then the signal handler could record that the signal was
>> delivered rather than actually call waitpid.  In any case, waitpid won't
>> block, so I expect the signal handler would take on the order of a
>> millisecond (this would really have to be tested, though, to know).
>>
>> Also, the user could still provide a dedicated thread by blocking
>> SIGCHLD in every thread but one, without any special support in
>> boost.process.
>
> If you call waitpid(-1,...) in aloop inside a signal handler, then you get the pids of the children. What do you do next? Keep in mind that the functions you can call must be obstruction-free/async-safe.
> How do you tell the other threads your pid you got from waitpid()?

The status for each child could be written to a designated pre-allocated 
data structure, and the thread could be notified by writing a single 
byte in non-blocking mode to a designated pipe.  If the write fails 
because the pipe buffer is full, it isn't a problem, because it means 
the reader end has yet to receive some previous notifications and will 
therefore still see the new status.