Date: Tue, 27 Jul 2021 18:58:16 +0300
On Tue, 27 Jul 2021 at 18:46, Henry Miller via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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]
Aye. These are apples and oranges; signals and slots are a particular
way to help structure your application (or library, whatever code),
whereas
POSIX signals are an IPC mechanism. The latter isn't a foundational
part of the former.
<std-proposals_at_[hidden]> wrote:
>
> 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]
Aye. These are apples and oranges; signals and slots are a particular
way to help structure your application (or library, whatever code),
whereas
POSIX signals are an IPC mechanism. The latter isn't a foundational
part of the former.
Received on 2021-07-27 10:58:29