[c++-pthreads] Re: thread-safety definition

[Dave Butenhof]

David Abrahams wrote:

>Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
>  
>
>>David Abrahams <dave at boost-consulting.com> writes:
>>
>>| Dave Butenhof <David.Butenhof at hp.com> writes:
>>| 
>>| >>The problems with catch(...) eating all exceptions are maybe not as
>>| >>bad as you think.  As a matter of fact, there are vanishingly few
>>| >>exceptions that demand special recovery actions that wouldn't work for
>>| >>all other exceptions.  Systems designed that way tend towards
>>| >>fragility.
>>| >>
>>| > I see an immense difference between a pragmatic statement that "in
>>| > practice there seem to be few exceptions" and something on which
>>| > cross-platform, mixed-language, modular environment programmers can
>>| > depend as a law. C++ does not say that "all exceptions can be
>>| > finalized and recovered fully by performing these steps". To presume
>>| > they can is fragile.
>>| 
>>| It also doesn't say "no destructors will throw exceptions", but we
>>| generally rely on them not to, because it makes programs hard to
>>| write.  There are a whole host of things we leave up to good
>>| programming practice, most of which don't have to do with EH.
>>
>>Agreed, but we can't specify things like that.  If we assume some
>>working hypothesis to hold, then we have to make that assumption clear
>>in the specification.  I think that is the point Dave Butenhof was
>>making. 
>>    
>>
>I didn't think so, at all. I hope Dave will clarify on his own,
>though, especially if I'm wrong.
>  
>
Um, well, in a way I guess that is what I'm saying, though I was coming 
from a different angle and going someplace difference. I was really just 
casually commenting that, in general, a policy of grabbing all passing 
exceptions and smashing them indiscriminately into the ground didn't 
seem like a particular healthy strategy.

If the standard doesn't say that "all exceptions can be silently 
finalized without any special action", then I think any program that 
tries to do this with arbitrary exceptions is asking for trouble. It's 
not reliable, it's not portable, it's arguably not "correct".

You offer the counter-argument that the same can also be said for code 
that raises an exception that requires special action -- except, one 
must allow, where it can also be sure that it will control finalization.

But the standard, apparently, neither supports nor refutes either view. 
Which is very likely as it should be, since the standard applies to all 
sorts of special circumstances where trying to describe this sort of 
business just gets confusing and doesn't really help anyway.

>AFAICT the discussion is about whether it makes sense to support
>programs which do catch(...) without rethrowing, and if so, how.
>Right now we're discussing a morality issue: "is it inherently evil to
>catch(...)  without rethrowing?"
>
>My point is that one could just as well (and perhaps more justifiably)
>claim that it's evil to throw any exception that can't be dealt with
>via a catch(...) block that doesn't rethrow, where that block was
>designed to handle, say, bad_alloc.**
>  
>
The real issue isn't so much catching without a re-throw, but catching 
and dropping arbitrary exceptions. If you don't claim to know how to 
finalize a bad_alloc error, what business do you have catching it? (And 
since catch(...) is anonymous, even if you could handle it you can't 
identify it.) I'm not convinced there's any rational excuse for 
finalizing bad_alloc unless you know how to free up some memory to 
"cure" the problem that caused it. (Nor would there be any particular 
benefit.) If you can't deal with it, you need to let it propagate to 
someone who can; or to terminate the process.

In the case of cancel, it's possible (though not "inarguably correct") 
to define the exception's destructor to re-cancel. There's no good 
analogy for bad_alloc, though; you can't just free arbitrary objects and 
presume the application can continue. But, sure, this could be argued 
back and forth forever, and it's not strictly relevant to the "charter" 
of this group...

>(**) this isn't really about the exception objects, but about the
>conditions of program state they represent.
>  
>
Certainly true, at least to the extent that if the exception doesn't 
represent a "program state", it may not matter; and if it does, then at 
least in many cases the situation will be self correcting. (That is, 
when you drop bad_alloc on the floor, either the situation has been 
corrected -- whether deliberately or simply by unwinding some set of 
frames with local objects -- or else it'll reassert itself soon enough.)

There seems to be some disagreement over where cancel fits in this 
spectrum. It is a sort of program state (actually, thread state), and 
can't simply be thrown away (in normal applications) without breaking 
program semantics. On the other hand, it's a "one shot" that won't be 
automagically reasserted. Jason's model resolves this by making it 
artificially self-reasserting, via the exception object's destructor. 
Alexander argues against this. I think I'd be happy with an automatic 
re-cancel on a catch(...), but ideally I'd also like someone to be able 
to catch(cancel) without needing to do something extra (even a 
'cancel.finalize()') to prevent re-cancellation. Given widespread use of 
catch(...), though, I'm willing to accept that "re-cancel on destruct" 
might be the least objectionable compromise.

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/