[PATCH] thread cancellation via C++ exception

[Boris Kolpackov]

Scott Lamb <slamb at slamb.org> writes:
 
> A couple questions:
> 
> 1) Can it be caught and rethrown?

Yes but can't finalize it (in other words the catch block should exit 
via `throw;').

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

Right, it is not allowed with my patch either. I agree it would be nice
to allow 'native' exceptions to propagate through corresponding parts
of call stack. It is not clear, however, how to detect 'cancellation 
refusal' in such cases. 

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

Same problem - no way to enforce cancellation.


> 2) What happens if the thread is canceled while a C++ exception is  
> already active?

terminate() will be called.

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

With my patch it prints

terminate called after throwing a `(anonymous namespace)::pthread_canceled'
  what(): N37_GLOBAL__N__ZNSt15thread_canceledD2Ev16pthread_canceledE
Aborted

which is what's expected.


> I think the ideal behavior would be to defer the cancellation until 
> the exception is handled.

Well, you can do it already in your dtor: if you are going to call
a cancellation point from your dtor (close() comes to mind) then
disable cancellation.

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

I stopped worrying about portability and feel noticeably better now ;-)


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

Are they still going to be cancellation points? For example, if I 
call your sigsafe_mutex_lock() and then cancel this thread (perhaps
through sigsafe_cancel()) will it still work? Note that according to 
the SUS pthread_mutex_lock "shall not return an error code of [EINTR]".


hth,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/phil-list/attachments/20040517/1ccebb66/attachment.sig>