Phil Bouchard
Founder & CTO
C.: (819) 328-4743
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.
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@lists.isocpp.org>
Envoyé : 26 juillet 2021 22:44:35 GMT+02:00
À : std-proposals <std-proposals@lists.isocpp.org>
Cc : Edward Catmur <ecatmur@googlemail.com>
Objet : Re: [std-proposals] Signals & Slots
On Mon, 26 Jul 2021, 21:32 Thiago Macieira via Std-Proposals, <std-proposals@lists.isocpp.org> 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