C++ Logo


Advanced search

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

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Fri, 31 May 2019 20:55:12 +0200
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.)


> 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_[hidden]
> http://www.open-std.org/mailman/listinfo/ub

Received on 2019-05-31 21:00:16