Boost logo

Boost :

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-02 10:16:31

Alexander Terekhov <terekhov_at_[hidden]> writes:

> 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. But instead of using ordinary
> exceptions, it uses "forced unwinding" for thread cancel and
> exit. For some unknown reason (other than "I say it must be
> so"), glibc maintainer Drepper of Red Hat simply refuses to
> even contemplate changing it to use ordinary exceptions instead
> of "forced unwinding"... and I suspect that is the reason why
> WG21 was asked to drop standardization of thread cancel (and exit)
> as exceptions.

That may be a contributory factor, but it's certainly not the only reason.

At the WG21 meeting in Oxford last April, Nick Stoughton made it quite clear
that POSIX cancellation is sticky --- you cannot catch it and resume
processing (as Dave Abrahams was keen to point out, you could write a cleanup
handler that didn't return, and then proceeded to do what the main function
would have done, but you couldn't then cancel the thread again). Exceptions
are not --- you can catch everything in catch(...), and you don't have to

Also, Howard pointed out that the C ABI for one of the Apple compilers doesn't
handle C++ exceptions in a way that would allow cancellation implemented as a
C++ exception to call pthread cleanup handlers in a C stack frame. Breaking
the C ABI to support the C++ thread library isn't nice.

I still like the exception-based cancel. Though interoperability with
pthread_cancel would be nice, it's not a must-have from where I'm sitting.


Anthony Williams
Just Software Solutions Ltd -
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

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