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: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-02-15 13:19:59

Am 15.02.2011 19:10, schrieb Jeremy Maitin-Shepard:
> 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.

Seams not reasonable for me - too much overhead.
The only possible way would be using a atomic variable which will be set 
by the signals handler that a SIGCHLD was delivered and the other 
threads running through a event-loop will detect the change of the 
atomic variable and then one thread would loop over waitpid( -1,...).