[ub] Draft 1 of Stackable, Thread Local, Signal Guards

Jens Maurer Jens.Maurer at gmx.net
Fri May 31 20:55:12 CEST 2019


On 31/05/2019 15.35, Niall Douglas wrote:
> On 30/05/2019 19:09, Jens Maurer wrote:
>
>> What's the interaction with the existing library facility
>> <csignal>?
>
> Many thanks for the useful question.
>
> I have added to the paper a FAQ item answering this. It is as follows:

I didn't mean: how do I impplement the new facility, I'm asking about
(possibly existing) programs that currently use <csignal> in at
least some part, and another part now starts to use your proposed
new facility, which seems to offer notification of a similar set of
exceptional circumstances (e.g. SIGFPE).

What does/should the specification say is supposed to happen?
(I don't care about implementation for now.)

Jens


> 6.2  What is the interaction with the existing library facility <csignal>?
>
> On POSIX only, signal guard could be implemented using <csignal>, apart
> from the additional signals described above, which are implemented by
> POSIX in any case. It is highly unlikely, however, that anyone would
> actually do so when POSIX’s sigaction() is far superior to signal().
>
> On non-POSIX, I would find it extremely unlikely that anybody would use
> <csignal> to implement this facility as, in this author’s
> experience,<csignal> implementations have a very low quality of
> implementation on non-POSIX platforms. To my knowledge, every non-toy
> non-POSIX system has a proprietary mechanism by which this facility
> could be completely implemented to a high degree of quality.
>
> Niall
> _______________________________________________
> ub mailing list
> ub at isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/ub
>



More information about the ub mailing list