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

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

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.


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.


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