Subj : Re: How to identify cancellation initiated stack unwinding?
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Fri Jul 01 2005 11:38 am

wij@seed.net.tw wrote:

> Hi:
> 
>  Based on the conclusion last time from this forum to upgrade my C++
> programs:
> 
>> ...
>> For the moment before The Standard, is it defensive enough to rewrite
>> my C++ programs on the base known -fact?- that:
>>   1. C system functions that are cancellation points implemented in the
>>      C++ library(Linux Fedora3+NPTL) will initiate stack unwinding on
>>      thread cancellation.
>>   2. The cancellation initiated stack unwinding might provide no type
>>      to catch.
>>   3. The final stuff as how to handle the unspecifed throw type is also
>>      yet unspecified.
> 
>>> David Butenhof wrote:
>>> "Facts" can be relative. For at least recent versions of NPTL, I believe
>>> your statements are essentially correct.
> 
> For now, I am rewritting the C++ thread class. Then, I found it
> difficult (if not impossible) not to identify the cancellation
> initiated stack unwinding in reusing pthread functions.
> Take for instance, the phread_create wrapper function usually would
> cancel the successfully created thread if it had someting wrong in
> the latter part of the function. Similar situation is in the thread
> class destructor (the thread is created detatched/deferred)
> Basically, pthread_exit had the same problem in addition to an
> exitcode to convey. Can you share some idea? (Fedora3 specific is
> enough). Thank you.

Detach (not in posix sense, in common english sense) the system level thread
from the object representation of the thread. Use start & stop methods
instead of constructor and destructors to create/destroy the system thread.
If the object is destroyed, stop & detach the thread, and immediately
destroy the object without waiting for the system to free the real thread.
If the thread is cancelled, set a flag or something alike in the object in
the cancelation handler routine, and let the object survive the thread
termination.

By decoupling phisical threads and their object representation, and using
objects to MANAGE phisical threads instead of REPRESENTING them, you can
bypass many problems.

.