Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Dave Butenhof <David.Butenhof@xxxxxx> writes:

> Sometimes I'm guilty of writing far too much detail, and I've learned
> to try to keep it simple and direct, at least "most of the time", and
> then I always get hit with a complaint that I didn't cover all the
> bases. You really can't win, can you? ;-)

I wasn't complaining.  I really thought you were trying to make a
blanket rule.  Many of the things you have written seemed to indicate
that you thought it was always a mistake to finalize a catch(...).

> Yes, of course there are exceptions; mostly in outer level control
> structures, though, not in the inner depths of a library. I've always
> argued it should be POSSIBLE to finalize any exception, including
> cancel; and in fact that's one of the major reasons I've always felt
> that cancel should BE an exception, since the syntax is already there.

Good; we agree.

> The issue we've been discussing is not whether there are exceptions,
> or where they are, but rather how to "warp" our basic theoretically
> clean model to deal with the reality that C++ libraries (including
> STL) are rife with arbitrary catch(...) blocks that stop exceptions;
> often with no really supportable reason except that it seemed
> convenient at the time.

Excuse me, but that is just wrong.  How many C++ libraries' EH code
have you examined?  That approach is hardly ever taken by C++
libraries I've seen, and if there are any such instances in a C++
standard library implementation they exist in the iostreams code which
is not part of what people call the STL.  Unfortunately, iostreams
were written before EH was really available and IMO they're a knotty
and old-fashioned design that's had some EH capability bolted on.
They have a "throwing mode" where exceptions are never stopped, and a
"non-throwing" mode where exceptions are turned into "state bits".
Even that, though I don't neccessarily agree with it, was done for a
reason.

> Most of this code should NOT be continuing when an exception occurs
> they can't directly finalize; they should be passing it on to
> someone who can. 

And that's what libraries generally do.

> That might be some outer scope that really understands the
> exception, or it might be some "failsafe catchall" in the main
> program loop like you're describing. We can keep this inner code
> from seeing cancel, we can keep it from catching it, we can re-raise
> cancel after the catch, or we can just let it trash the cancel and
> force the code to be fixed if the user really wants that thread to
> be cancellable while in the library.
>
> Note that my (hypothetical, simply for the purposes of abstract
> consideration) proposal for dynamic cancel scoping based (at least
> partly) on exception constructs, would result in cancel being
> completely disabled in any thread run by your "recover at all costs"
> main loop; because the entire call tree would be inside a catch(...)
> scope. 

That catch(...) block would only be in the program's main thread, which
probably shouldn't be cancelled anyway.


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