Re: Behaviour of __forced_unwind with noexcept

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 13 August 2017 at 19:20, Ron wrote:
>
> Hi,
>
> I'm looking for some clarification of how the __forced_unwind thread
> cancellation exceptions intersect with noexcept.  I've long been a
> big fan of the __forced_unwind idiom, but now that C++14 is the default
> since GCC 6.1, and many methods including destructors are implicitly
> noexcept, using it safely appears to have become a lot more tricky.
>
> The closest I've found so far to an "authoritative" statement of the
> expected behaviour is the comments from Jonathan Wakely here:
>
> https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>
> In particular: "It interacts with noexcept as you'd expect:
> std::terminate() is called if a __forced_unwind escapes a noexcept
> function, so noexcept functions are really noexcept, they won't
> unexpectedly throw some 'special' type"
>
> Which does seem logical, but unless I'm missing something this makes
> it unsafe to perform any operation in a destructor which might cross
> a cancellation point, unless that destructor is noexcept(false).

Unfortunately I still think that's true.

This was also raised in https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html

> And since that could be something as simple as logging to stdio and
> almost impossible to definitely rule out in a future proof way if the
> destructor does anything non-trivial (like calling functions in a
> system or other 3rd party library) ...  and since the race of catching
> a cancellation request in such a destructor could be a relatively rare
> one to lose in a lot of code ...  there could be a lot of extant code
> with new latent 'crasher' bugs when built with GCC 6.1 or later.
>
> And/or a lot of people are going to have to go through a lot of code
> and mark up a lot of methods with noexcept(false).
>
>
> So I'm half-hoping that I am actually missing something here which
> mitigates that - but if not, is this something we need to give a
> bit more thought to?
>
> (Please keep me cc'd, I'm not currently on this list)
>
>   Cheers,
>   Ron
>