C++ Logo

std-proposals

Advanced search

Re: Signals & Slots

From: Phil Bouchard <boost_at_[hidden]>
Date: Mon, 26 Jul 2021 15:27:16 -0400
What is messy with them is if a process receives a signal and the main
thread masks it then it will be forwarded to the first random thread not
masking it.

Perhaps there is a solution to wrap them up or perhaps there is none; I
don't know yet.

On 7/26/21 3:16 PM, Thiago Macieira via Std-Proposals wrote:
> On Monday, 26 July 2021 03:36:48 PDT Antoine Viallon via Std-Proposals wrote:
>> On CLI applications, they are almost mandatory to use!
>> If you do not catch them, the OS can kill your process "brutally" before you
>> can clean things up…
> Ok, so don't use them for new cases. For existing cases like catching a SIGINT
> or SIGHUP, that's fine. You also can't avoid handling SIGCHLD if you have
> child processes, unless you require Linux 5.4 or later.
>
> The problem is that the POSIX / Unix signals are extremely hard to use in a
> library. It's impossible to install one thread-safely and it's impossible to
> remove one that you installed, at all. They can only be used by the
> application -- any library using them (aside from SIGCHLD) must be doing it on
> behalf of the application. That's the case of SIGINT that terminates the
> application, SIGHUP that tells the application to reload its configuration, or
> SIGTERM to exit cleanly.
>
> Therefore, please don't invent new use-cases for them.
>
-- 
*Phil Bouchard*
Founder & CTO
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>

Received on 2021-07-26 14:28:05