Subject: Re: [ub] Draft 1 of Stackable, Thread Local, Signal Guards
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-06-01 17:27:30
On 31/05/2019 19:55, Jens Maurer wrote:
>>> What's the interaction with the existing library facility
> 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.)
I was going to leave it as "implementation defined", so on some
implementations mine uses <csignal> and thus conflicts with other code
using signal(), but on other implementations they are totally independent.
Is this acceptable to SG12?
If not, and particularly if a majority on SG12 agrees me with that
signal() is almost useless and almost no newly written production code
written in the past 20 years has used it, would SG12 prefer to see a
proposed wholesale replacement for signal(), which we send to deprecation?
(Before someone asks "isn't that a WG14 C decision?", yes it is. However
I had a few informal conversations at the London WG14 meeting, and it
was widely agreed that signal() is not fit for purpose. However, it was
also felt that sigaction() is too POSIX-specific to be standardised into
C. So they are open to a proposed wholesale replacement, if it is
generic and not platform-specific. Like my proposal)
SG12 list run by herb.sutter at gmail.com