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 00:38:34

On 02/14/2011 06:12 PM, Oliver Kowalke wrote:
> Am 15.02.2011 02:44, schrieb Jeremy Maitin-Shepard:
>> Yes, it would be delivered to an arbitrary thread, but as signal handler
>> settings are shared between threads, it would only be necessary to call
>> signal/sigaction once.
>
> Why do I need multiple threads doing the same? One thread handling
> signals is sufficient. Delivering the signals ansyc. with sigaction()
> etc. is dangerous in a multi-threaded app because if the code locks a
> mutex and then handles a signal delivered asynchronously with let the
> mutex be locked during the signal handling and may let the mutex be
> locked forever if the thread exits.

Naturally the signal handler shouldn't terminate the thread.

An important case is when there is just a single thread in total, in 
which case using a dedicated thread for signal handling would be excessive.

> This is not what you want at least how long the mutex remains locked
> should not depend on asnyc. signal handlers.

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.