Re: [PATCH] thread cancellation via C++ exception

[Scott Lamb <slamb slamb org>]

On 11 May 2004, at 3:17 PM, Boris Kolpackov wrote:

> When HAVE_FORCED_UNWIND is defined nptl uses forced unwinding of  
> exception
> handling mechanism (should we call it ABI exception handling?) to  
> unwind
> the stack and call cleanup handlers. This allows catching cancellation
> exception with C++ catch(...) handler.
>
> This patch makes nptl throw a C++ exception (std::thread_canceled,  
> defined
> in pthread.h) during thread cancellation. As a result you can use typed
> handler to identify this situation:

A couple questions:

1) Can it be caught and rethrown?

I read an earlier thread in which someone mentioned using  
boost::python. He wanted to catch the cancellation, throw an equivalent  
Python exception, and rethrow the C++ exception at the other end. This  
is not allowed currently in NPTL.

I'd like to be able to do something similar with C code that is not  
cancellation-safe. OpenSSL, for example. It would be prohibitively  
difficult to modify these libraries to use cancellation and get the  
patches integrated upstream, but much easier to propogate a C error  
code through then rethrow the exception at the other end. No changes to  
the C code would then be required.

2) What happens if the thread is canceled while a C++ exception is  
already active? Unless my test is flawed (it's at   
<http://www.slamb.org/svn/repos/projects/cancellation_tests/ 
test_cancellation_while_throwing.cc>) or NPTL's behavior has changed  
since the version I tested, it will abort with "terminate called  
without an active exception". I think the ideal behavior would be to  
defer the cancellation until the exception is handled.

I probably wouldn't use it, even if your patch allowed me to do these  
things. I've given up on pthread cancellation, due to bugs and the lack  
of standardization w.r.t. C++. This new behavior might be helpful for  
code intended to run solely under that environment, but for portable  
code new behaviors can only make things worse.

Instead, I'm working on implementing my own thing on top of my sigsafe  
library. None of the standard library functions will be cancellation  
points to my code (just sigsafe_XXX() system call wrappers and code  
that uses them), but that's life.

Thanks,
Scott