From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-07 08:01:35
> * Can not call any methods that represent cancellation points
> (remember, if a function foo calls a function bar that calls a
> function defined to be a cancellation point, then foo is also a
> cancellation point) in a method defined with empty throw
> specifications. Some argue that this is simply how it should be
> since obviously the method can throw if it calls a cancellation
> point. However, with other exception types you can catch the
> exception and not propogate it up past the call, while with a
> cancellation exception you have to rethrow the exception.
> * Can not call any methods that represent cancellation points from a
> destructor. It's a very frequent need to do just that, but doing so
> can result in an exception being thrown out of the destructor which
> disallows the object from inclusion in many container types and when
> created on the stack can result in application termination if the
> stack is being unwound because of another thrown exception. The
> complexit in this case is too great to be safely usable.
that is true unless your function/destructor disables cancellation
on its entry (and restores the previous state on its exit). that is
the standard practice to write cancellation-safe code. what is
needed is simply a cancellation "guard" class, IMHO.
you might have a look at the following Compaq document
(appears to be freely available on Compaq web site):
"Canceling a thread means requesting the termination of a
target thread as soon as possible. A thread can request
the cancelation of another thread or itself.
Thread cancelation is a three-stage operation:
1. A cancelation request is posted for the target thread.
This occurs when some thread calls pthread_cancel( ).
2. The posted cancelation request is delivered to the target
thread. This occurs when the target thread invokes a routine
that is a cancelation point. (See Section 220.127.116.11 for a
discussion of routines that are cancelation points.)
If the target thread's cancelability state is disabled,
the target thread does not receive the cancelation request
until the next cancelation point after the cancelability state
is set to enabled. See Section 18.104.22.168 for how to control a
3. The target thread might have pushed cleanup handler routines
(using the pthread_cleanup_push( ) routine) on its handler stack.
When the target thread receives the cancelation request, the
Threads Library unwinds the thread's call stack. For each frame,
active exception handlers are invoked. These include cleanup handler
routines, C++ object destructors, Compaq C SEH except clauses, and
C++ catch(...) clauses."
"A thread's cancelability state determines whether it receives a
cancelation request. When created, a thread's cancelability state
is enabled. If the cancelability state is disabled, the thread does
not receive cancelation requests, instead, they remain pending."
ps. also, you might have a look at "thread object" related
description(s) in that document as well.
btw, posix standardization process (drafts, etc):
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk