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 >
