This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Behaviour of __forced_unwind with noexcept
On Tue, Aug 15, 2017 at 05:37:21PM +0100, Szabolcs Nagy wrote:
> On 15/08/17 16:47, Richard Biener wrote:
> > On Tue, Aug 15, 2017 at 5:21 PM, Ron <ron@bitbabbler.org> wrote:
> >> Is changing the cancellation state really an expensive operation?
> >> Moreso than the checking which I assume already needs to be done for
> >> noexcept to trap errant exceptions?
> >
> > The noexcept checking only needs to happen if an exception is thrown
> > while the pthread cancel state needs to be adjusted whenever we are
> > about to enter/exit such function.
> >
> >> If it really is, I guess we could also have an attribute which declares
> >> a stronger guarantee than noexcept, to claim there are no cancellation
> >> points in that scope, if people have something in a hot path where a few
> >> cycles really matter to them and this protection is not actually needed.
> >> Which could also be an automatic optimisation if the compiler is able to
> >> prove there are no cancellation points?
> >
> > I guess that's possible.
> >
> > I suppose prototyping this would be wrapping all noexcept calls in
> >
> > try { pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &old); call
> > (); } finally { pthread_setcancelstate (old, &old); }
> >
>
> i think changing the state this way is only valid if call
> itself does not change the state, which we don't know.
That's a fair statement, but we're only talking about doing this in
functions which are declared noexcept.
It already requires the person writing that code to ensure that
no exceptions are thrown (else the process will terminate), and
this extension would additionally require them to ensure that no
cancellation points become active (which is already required now
anyway since that's already directly equivalent to throwing an
exception as things are now).
The only difference is the compiler can do it safely, where trying
to write that explicitly in user code will still leave gaps where
an unwind exception could leak out.