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

[Scott Lamb <slamb slamb org>]

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