Anthony Williams wrote:
"Phil Endecott" <spam_from_boost_dev@chezphil.org> writes:
Alexander Terekhov wrote:
Anthony Williams wrote: [...]
N2420 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2420.pdf) covers some of the relevant ground --- it's the minutes of the POSIX/C++ liaison committee.
"Gnu gcc and Solaris pthreads: The Gnu gcc and Solaris pthreads implementations are two known implementations that attempt to map POSIX pthread cancellation onto C++ exception handling, but both do so at the cost of breaking the exception model (i.e., they no longer conform to ISO C++) because the alternative appears to be that C++ destructors and catch blocks would not be invoked for cancellation which would mean that resources would be leaked."
Uhmm. Don't know about (modern) Solaris, but glibc (presumably that is meant by "Gnu gcc pthreads implementation") does invoke C++ destructors and catch blocks.
Realy??? Wow! Can you direct me to some documentation?
I can't find it documented anywhere sensible, but I've seen it discussed on mailing lists several times.
As I understand it, with gcc on linux, pthread_cancel will run destructors and catch(...) blocks in the cancelled thread, but if the catch(...) block doesn't rethrow the exception, it is automatically rethrown at the end of the block (like function-try-blocks do in constructors), so that the cancel is "sticky".
<rant>I can't believe how much time I have wasted trying to sidestep the need for cancellation, and investigating how to hack some approximation to cancellation into my application (e.g. by using processes and shared memory rather than threads), only to discover now that exactly the feature that I need is already present in glibc - just not documented by them.</rant> One of the good features of Boost is the high-quality documentation, so this sort of mistake wouldn't happen here, would it? So now there's a choice: - The pthread_cancel functionality in glibc has cancellation points at blocking system calls, which is essential to me and I imagine to many people. But it doesn't throw catchable exceptions, which some people would like (but I don't need). - The approach that Anthony has described would have difficulty introducing cancellation points at system calls. But it generates catchable exceptions, and it's cross-platform. Having different thread classes with similar interfaces but different cancellation behaviour is not ideal, but neither is it inherently a huge problem. However, if I have some long-running loop that wants to do periodic cancellation tests, or if I'm writing a mutex, it needs to do different things depending on the kind of cancellation. Maybe some sort of per-thread function pointer for testcancel() is needed? Regards, Phil.