[PATCH] thread cancellation via C++ exception
Scott Lamb
slamb at slamb.org
Mon May 17 20:28:48 UTC 2004
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
More information about the Phil-list
mailing list