Re: Digest Number 754

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):

http://tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9RBTE/TITLE.HTM
http://tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_PDF/ARH9RBTE.PDF

"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 2.3.7.4 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 2.3.7.3 for how to control a
    thread's cancelability.

 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."

regards,
alexander.

ps. also, you might have a look at "thread object" related
description(s) in that document as well.

btw, posix standardization process (drafts, etc):

http://www.opengroup.org/austin/