[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]