Subj : Re: pthread function behavior in C++ program
To   : comp.programming.threads
From : David Butenhof
Date : Sat Jun 11 2005 07:13 pm

Chris Vine wrote:
> David Butenhof wrote:
> 
> [snip]
> 
> 
>>If you expect to be working exclusively with a C++ implementation that
>>exposes cancellation as exceptions, then you definitely should use the
>>native C++ mechanisms instead of pthread_cleanup_push/pop. On some
>>implementations (e.g., Tru64 UNIX and OpenVMS), the C macros won't even
>>work correctly (or possibly at all) from C++ (they're based language
>>extensions to integrate with the native platform exceptions that the C++
>>compiler doesn't support).
> 
> 
> How far down the stack is an exception thrown by virtue of a call to
> pthread_cancel() expected to go in a well-designed system, for those which
> expose cancellations as exceptions (as I believe NPTL now does when
> executing in a C++ environment).  Should it propagate to the point at which
> the thread ceases executing (terminate the thread), or should it go
> further?  If it tries to propagate beyond that point I can't see it could
> do much more than terminate the whole process within which it was
> executing.

"Should" is a difficult question -- it depends a lot on perspective and 
background. Thread cancellation (and exit) are thread-local exceptions. 
They "can" (should) never be allowed to propagate beyond the thread's 
start routine. If not finalized by the application's thread code, the 
thread library's trampoline frame should handle it by terminating the 
thread (and setting it so pthread_join() will return the required 
PTHREAD_CANCELED termination status).

But of course technically that's all POSIX -- and my expectations and 
prejudices. There are C++ people who argue that an unhandled exception 
should always terminate the process. There are some who argue that 
cancel and exit should not be "catchable" -- as Alexander points out 
this is what Linux currently does, with a "forced unwind" rather than a 
true exception. That is, it'll run object destructors, but cannot be 
caught. (This is in a way compatible with POSIX, since there's no 
mechanism in POSIX to "finalize" a cancel/exit exception; they'll run 
cleanup handlers [destructors] until the thread is completely unwound, 
and then terminate the thread.)

Anyone who says "should" in this area is merely arguing their particular 
point of view. There's no standard requirement for "C++ cancellation" 
that mandates any one common point of view.

If you want to know what's RIGHT, I'd be happy to tell you; but then I 
also know some would disagree with me. ;-)

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

.