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:53:57

On 02/15/2011 10:19 AM, Oliver Kowalke wrote:
> 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,...).

The only way to wake up the event loop, as far as I know, is to change 
the status of a file descriptor.  (The signal itself might cause a 
wake-up, but I don't think there is any race-free way to rely on that.) 
  I suppose your claim is that if all the signal handler is doing is 
simply notifying asio that a signal arrived, then it might as well be 
done using a generic signal handling library.  That is valid, but it is 
still an implementation detail, and therefore isn't really a concern. 
Doing it in the signal handler has the advantage of keeping the SIGCHLD 
handling relatively independent from asio.  For instance, it would then 
be possible to support a combination of synchronous and asynchronous 
waiting, and also perhaps allow interoperability with other libraries 
that want to manage processes.  It would require testing to know, but 
I'm not convinced that doing this work in the signal handler would add 
significant latency, e.g. more than would be introduced by random kernel 
interrupt handlers, and if latency is very important in certain threads, 
SIGCHLD (and all other signals) could simply be blocked in those 
threads.  The documentation could warn about this.