Behaviour of __forced_unwind with noexcept

[Ron <ron at bitbabbler dot org>]

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).

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