Re: [boost] Comments about N2320

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-02 14:39:01

Anthony Williams wrote:
> "Phil Endecott" <spam_from_boost_dev_at_[hidden]> 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.