[PATCH] thread cancellation via C++ exception
Boris Kolpackov
boris at kolpackov.net
Mon May 17 21:30:56 UTC 2004
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>
More information about the Phil-list
mailing list