This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Behaviour of __forced_unwind with noexcept
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Ron <ron at bitbabbler dot org>
- Cc: nd at arm dot com, Jonathan Wakely <jwakely dot gcc at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 15 Aug 2017 17:37:21 +0100
- Subject: Re: Behaviour of __forced_unwind with noexcept
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <20170813182002.GJ12030@hex.shelbyville.oz> <CAH6eHdRgU6GVYJ5WD4480JJ_qOD1oYzN4UC+4SDirFdp8yj=1Q@mail.gmail.com> <20170815044413.GT12030@hex.shelbyville.oz> <CAFiYyc0iaN082icVjeT4bdGv4OYbVFBnpX+LX7Ncc7Mt=znnAQ@mail.gmail.com> <CAH6eHdQV3ooZRgi6i+Zh=WvYrKOSrcGA-E3F+mxvef7nW-o2vw@mail.gmail.com> <CAFiYyc3G_MoENbWsfXhNUSKcf6cLD-oLD5Eu71sBs8rDCULitg@mail.gmail.com> <20170815152142.GW12030@hex.shelbyville.oz> <CAFiYyc157R96X=6RoTKVGLZp=_qCP_ak+3g=sX5YYs3rZKK4yQ@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.