Boost logo

Boost :

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 (
>>>> 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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at