Yeah if we don't abstract POSIX signals, people will come up with a
million different messy alternatives. The costs / benefits are there I
think and it's trivial to implement anyways.

On 7/27/21 5:37 AM, Antoine Viallon via Std-Proposals wrote:
> No, but this is really interesting.
> I needed a clean way to handle signals.
>
> And, for reference, new code bases don't have signal handling code.
> And I really think POSIX signal handling helpers in the STL would make
> everybody's life easier.
>
> Antoine Viallon
>
> ------------------------------------------------------------------------
> *De :* Edward Catmur via Std-Proposals <std-proposals_at_[hidden]>
> *Envoyé :* 26 juillet 2021 22:44:35 GMT+02:00
> *À :* std-proposals <std-proposals_at_[hidden]>
> *Cc :* Edward Catmur <ecatmur_at_[hidden]>
> *Objet :* Re: [std-proposals] Signals & Slots
>
> On Mon, 26 Jul 2021, 21:32 Thiago Macieira via Std-Proposals,
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>> wrote:
>
> On Monday, 26 July 2021 12:54:07 PDT Phil Bouchard wrote:
> > ... or to create some "process singleton" already emitting these
> converted
> > signals. On 7/26/21 3:51 PM, Phil Bouchard via Std-Proposals wrote:
> > One thing that could be done though is to provide a static
> conversion
> > function called explicitly that will convert these POSIX signals
> into the
> > new safer signal types. Just an idea...
>
> That is what I call "new use-cases".
>
> No, thanks. Whoever needs to deal with POSIX / Unix signals
> already has the
> code. I don't really care to make their lives easier.
>
>
> Hopefully everyone is aware of asio signal_set?
> https://www.boost.org/doc/libs/1_76_0/doc/html/boost_asio/overview/signals.html
> <https://www.boost.org/doc/libs/1_76_0/doc/html/boost_asio/overview/signals.html>
>
>

-- 
*Phil Bouchard*
Founder & CTO
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>