> Well, since thread cancellation is implemented using exceptions, and thread cancellation can happen in arbitrary places, we’re always liable to a cancellation happening in a noexcept block, which is undefined behavior, and which in practice will cause your program to crash.<p>I believe the author is mistaken here: throwing an exception that reaches the end of a noexcept block is <i>not</i> undefined behaviour; it will call std::terminate per [except.spec] [1].<p>The linked mailing list post [2] makes no mention of UB, only that this might cause exceptions to be thrown unbeknownst to the programmer in implicitly-noexcept blocks (i.e. destructors) which now might need a noexcept(false) to avoid std::terminate (although that’s still not great because throwing from a destructor will likely lead to resource leaks even if it’s handled).<p>[1] <a href="https://timsong-cpp.github.io/cppwp/n4868/except.spec#5" rel="nofollow">https://timsong-cpp.github.io/cppwp/n4868/except.spec#5</a><p>[2] <a href="https://gcc.gnu.org/legacy-ml/gcc/2017-08/msg00121.html" rel="nofollow">https://gcc.gnu.org/legacy-ml/gcc/2017-08/msg00121.html</a>
The cancellation is the main reason why I usually end up with async frameworks in C++ (like boost::asio). When you have explicit event loop, the whole cancellation thing is so much easier to reason about.<p>And even if your don't want to do full-featured event loop and like synchronous style, it's pretty simple to add "poll" call to each network read (on just 2 descriptors: "termination pipe" and the FD you are interested in). Sure, it requires a custom wrapper for read/write/connect, but so is author's proposed signal-safe syscall.
I burned myself with threads back in the day under AIX when I had this process creating and destroying them, and after destroying them they were still visible and their resources still there. A few posts on Usenet (good times!) and knowledgeable people instructed me on what a thread pool was and why I should have used one instead of creating and destroying threads. I can't give more details, that was like 25 years ago and my memory modules have no parity check, but the experience was very instructional.
Thread cancellation works fine in C++.<p>You just need to make sure cancellable syscalls do not happen in destructors. (Which you probably want to do anyways, since cancellable syscalls can cause errors that are difficult to handle in destructors.)<p>Good practice is to move destructed objects to a "garbage collection" thread which calls the real destructors and cannot be cancelled.