thread-safety definition

[David Abrahams]

Matt Austern <austern at apple.com> writes:

> On Jan 12, 2004, at 5:41 AM, Dave Butenhof wrote:
>
>> I think I disagree, at least philsophically, with the
>> characterization of the model as "fragile". But I think I also
>> understand what you mean; and the problem isn't with the model, but
>> rather with the effect of that model on existing code that
>> all-too-casually and agressively eats exceptions it doesn't
>> understand. I think there are vanishingly few circumstances where a
>> blind catch(...) without an unconditional re-throw should be
>> considered "legitimate". If you don't completely understand what an
>> exception means, you cannot claim to have completely recovered, and
>> therefore cannot reasonably finalize propagation. (And when you
>> catch anonymously, you can't possibly understand what they mean
>> since you can't even identify them.) On the other hand, regardless
>> of whether the semantics are meaningful or reasonable, the syntax is
>> legal and apparently (unfortunately) in common use, so I can't
>> dispute that you need to consider that.
>
> One legitimate use for that pattern is in mixed-language programming,
> when you write a little adapter to turn the error reporting mechanism
> used by the C++ part into an error reporting mechanism that the C part
> can understand. I think that's reasonable for most of the things
> exceptions are used for.  It isn't reasonable for thread cancellation,
> because C needs to know about thread cancellation too.

Well, how do you propagate the cancellation to 'C'?  Surely not by
letting the C++ exception leak out into C-land, except on very special
systems where the C runtime knows about EH.  In that case, you have to
finalize the exception and frob some 'C' cancellation reporting
mechanism.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com