[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Dave Butenhof]

Alexander Terekhov wrote:

>> (only). If caught anonymously, they must be re-thrown. 
>>    
>>
>This "compromise" makes no sense.
>  
>
Of course it "makes sense" -- you just don't agree. You're correct that 
in your specific contrived example, "catch only cancel" and "catch 
anything in a context where there can be nothing but cancel in the first 
place" end up the same; however that's a very specific counterexample. 
In the general case, there's no way to be sure the author knows that 
"catch(...)" is semantically equivalent to "catch(thread_cancel_request 
const &)" -- and even when the compiler and runtime could know, I'd 
rather not have it making special cases like that. For example, change 
the context to allow a second exception, and now the catch(...) is 
ambiguous.

But this is also an example of my quandary in this discussion, and why 
I've often tried to stay quiet. I don't want to be here as a C++ 
consultant -- I don't qualify in that respect. I'm trying to help out as 
a thread semantics consultant, because I do have a lot to offer in that 
respect. I really don't want to get into arguing the details of C++ 
syntax and semantics; just the general mechanisms and rules of 
interaction at the interface between "language" and "threads". It's a 
tenuous boundary that's often difficult to chart, to be sure; but I 
think you're trying to pull me over the line and I'd rather resist. ;-)

I've just returned from a week vacation, including a fairly nasty 
thunderstorm our last night that left the camp without power and with a 
lot of downed trees and such. It was probably foolish to even connect to 
my work email today, but I did, and I'm faced with what appears at a 
quick scan to be on the order of 100 messages in this discussion. Ouch. 
I've done my token declaration of return by taking Alexander's isolated 
response to my message, but I'm not going to even approach the others 
until I've gotten back "into the swing" next week.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.butenhof.vcf
Type: text/x-vcard
Size: 476 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/c++-pthreads/attachments/20050723/c47b1115/attachment.vcf>