Roland Schwarz wrote:
Howard Hinnant wrote:
I swear (lays hand on backup disk) on my backup disk, all N2184 (and N2178 as I understand it) wants of C++ cancellation is to request that the target thread (whenever it gets around to it, if ever) throw a normal C++ exception, which the target thread is free to subsequently catch, swallow and digest. :-)
To be honest. I did not yet had time to study N2184 and 2178. But if this is true, wouldn't this be in contradiction to pthread semantics? Wouldn't this users rather confuse even more?
Indeed, I think these are two very different things: 1) Request a thread cancelation. This is what in POSIX threads is called pthread_cancel(), and what you presumably mean by "t.raise(cancel_exception)". 2) Notify that a thread has been canceled. This is what would presumably result in a thread_canceled exception being thrown. As far as I understand, the desired semantics here would be 'deferred', i.e. 1) is really only a request, i.e. at the point this call returns there is no guarantee that the cancellation has been terminated (or even initialized). Note that you suggested "t.raise(std::thread_canceled)", which sounds misleading, since 'canceled' suggests this is raised at the point where the cancelation is finished, not requested. For that matter I don't really see the point in using an exception to signal the 'cancel request' to the target thread, while the use of an exception in 2) makes a lot of sense, since the main discussion (as far as POSIX threads & C++ is concerned) is about the cleanup, i.e. the missing stack unwinding semantics. (Part of the discussion is about whether the exception can be caught without being rethrown in handlers such as 'catch (...) {}', or whether catch(...) should see thread_canceled at all, etc.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...