[PATCH] thread cancellation via C++ exception
Scott Lamb
slamb at slamb.org
Tue May 18 03:14:08 UTC 2004
On 17 May 2004, at 4:30 PM, Boris Kolpackov wrote:
> 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'm not sure why this is necessary. Ulrich, you've stated that threads
must not refuse cancellation. Okay; then any such program is Seriously
Broken(TM) and its behavior is undefined. But it's already impossible
to detect all broken programs. And here the attempt to do so seems
harmful - if libc didn't try, then the situations I mentioned would be
possible.
>> 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.
Okay.
> I stopped worrying about portability and feel noticeably better now ;-)
That must be nice. :/
>> 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]".
I'll send you a private email about this; I'm sure my library is boring
to Ulrich and folks.
Thanks,
Scott
More information about the Phil-list
mailing list