Scott Lamb <slamb 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
Attachment:
signature.asc
Description: Digital signature