Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk