I think this is a generally useful thing to explore, but it definitely
needs to go through SG1 first because it affects the memory model.
SG1 spends a considerable fraction of its time pondering the progress
guarantees around signal handling, and it interacts with all the SG1
facilities in a pretty deep way (e..g: lock-freedom).

I'd like to understand the discussion of setjmp/longjmp. Why not talk about
sigsetjmp/siglongjmp instead? They're primitives built for this purpose,
whereas setjmp/longjmp aren't.

Right now signal supports SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV,
SIGTERM. You're expanding that list. It would be good to discuss this
expansion, as well as how your proposal interacts with existing signal
support.

On Thu, May 30, 2019 at 8:58 AM Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> Dear SG12,
>
> CC: Herb Sutter
>
> As we limber up to the Cologne mailing deadline, here is draft 1 of a
> proposal to add stackable, thread local, signal guards to the C++
> standard library. It will be submitted for SG12 to review at Cologne.
>
> A signal guard allows one to recover from a hardware exception during a
> guarded piece of code e.g. SIGFPE, SIGSEGV, and so on. The guard acts on
> the local thread, rather than globally. And they can be stacked, one
> inside another.
>
> They also can guard against OOM and termination, which may be useful for
> Herbceptions' proposed OOM handling changes.
>
> A reference library implementation is linked, it's been in production
> for over a year now, and has proven quite popular with many people as it
> abstracts away lots of annoying implementation specifics.
>
> Comments welcome.
>
> Niall
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>