Mike Dalpee <mikedalpee@xxxxxxxxxxxx> writes: > But here's the thing. With Solaris C++, thread cancellation just worked - when a thread is cancelled, the stack is unwound, destructors run, and there is no visibility outside the runtime of the mechanism used to accomplish that. I guess I don't see why the g++ runtime could not do the same thing, and rather than exposing the "foreign" thread cancellation exception abi::__forced_unwind to the outside world, thereby requiring special handling for it to even have a chance of working properly, instead keep it hidden and treat it as a one-of-a-kind, special "foreign" exception that just causes stack unwinding/destructor execution. > > Of course, I realize this is likely the topic of much debate, and gcc's implemention is probably an attempt to be compliant with the evolving c++ standard. But clearly, g++'s approach is highly flawed, so perhaps the standard needs to be driven in a way such that g++ can ultimately provide the Solaris-style thread cancellation semantics. > > Unfortunately for me, this really causes huge problems with my porting efforts. In effect, it means there is no reliable way to cancel a thread that is written is C++ and uses exception handlers. Not sure how I am going to overcome that. I agree that this is a real bug. On the other hand I've always considered asynchronous thread cancellation to be a rather shaky proposition. Apparently Solaris has managed to do a good implementation of it, but it's never going to be portable. The root issue here is that glibc implements thread cancellation as an exception, using the language independent exception mechanisms. Those mechanisms are designed to let one language catch an exception thrown by another language, which is not what you want to have happen here. In fact this exception should not be caught at all. Glibc does this because it lets it rely on the existing exception mechanisms to efficiently implement pthread_cleanup_push. It also lets pthread_cancel run C++ destructors; I don't know if that is a good idea or not. Does that happen on Solaris? I don't know if this is covered by any OS or language standards. C++ did not discuss threads at all before C++11, and as far as I know C++11 has no asynchronous thread cancellation facility. It's a collision of paradigms and I don't know what the right answer is. If pthread_cancel is going to run C++ destructors, then the next question is whether a catch(...) should catch a cancellation. I can see arguments both ways on that question. If pthread_cancel is not going to run C++ destructors, matters are a little simpler. We would just need a way for glibc to create an exception that C++ will ignore. I would encourage you to file your two test cases as two separate bugs in http://gcc.gnu.org/bugzilla so that these issues are not forgotten. Ian
