IF (big if) we have a signal/slot framework in C++ we should get that first. Then let third party libraries do the POSIX translation. After a few years we can look at the libraries and decide what/if the correct way to add POSIX to our system is.

POSIX adds a bunch of rules that I don't want in the generic signal handler framework. Though I'm open to be convinced otherwise if those rules really are worth the cost, but worth the cost wouldn't be to support POSIX, it would be [insert something I can't think of here]

Henry Miller

hank@millerfarm.com

On Tue, Jul 27, 2021, at 10:23, Phil Bouchard 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.

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

Std-Proposals mailing list