Re: [PATCH] thread cancellation via C++ exception
Scott Lamb <[email protected]> Mon, 17 May 2004 22:14:08 -0500
| Newsgroups | gmane.comp.lib.phil |
|---|---|
| Message-ID | <[email protected]> |
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