Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 17:27:43

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> To: <boost_at_y...>
> Sent: Monday, January 14, 2002 4:32 PM
> Subject: [boost] Re: first sight
> 
> 
> > --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > > The quoted POSIX rationale seems very similar to the
> > widespread "fear of
> > > exceptions" that was abroad in the land before we understood 
how to
> > think
> > > about them. It sounds like the POSIX designers weren't confident
> > they could
> > > figure out which operations should give the 'C' equivalent of 
the
> > nothrow
> > > guarantee, so they threw up their hands. Well, in fairness I 
think
> > they also
> > > were worried about the vast quantity of legacy 'C' code which
> > doesn't know
> > > how to support cancellation.
> > >
> > > I don't think we should approach this problem the same way:
> > >
> > > 1. We have the tools to think about exception-safety
> >
> > Well, POSIX does as well, at least to some extent. (True C++
> > exceptions with stack unwinding and destructors are much more
> > flexible.)
> 
> I don't mean the programmatic tools; I'm referring to the mental 
tools. We
> have a reliable and effective system of distinctions for 
understanding
> exception-safety, which operations can throw, and what their 
effects may be
> if they do.

OK.

> > Either the issues they saw are real, even for C++ using
> > exceptions, or they just didn't feel they had enough experience to
> > deal with it and took the easy way out.  Since I know nothing 
about
> > the process they went through to come to the decisions they made, 
I
> > won't try and guess here.  At some point I hope to convince some
> > people who were there to help out with making some decisions here.
> > This includes some of those that were there during the design of 
Java
> > as well.
> 
> Sounds good. I'll be the first to admit I'm jumping to conclusions 
about
> their thought process. However, it is clear to me that the decision 
one
> makes about whether to make mutex_lock to be a cancellation point 
is not
> mysterious, and shouldn't be affected much by the fact that 
mutex_lock is a
> threading operation. It's a simple question: must mutex_lock be a 
nothrow
> operation?
> 
> I think that if you can disable cancellation efficiently and 
mutex_lock only
> throws cancellation exceptions, then there's no problem making 
mutex_lock a
> cancellation point, since disabling cancellation effectively makes 
it
> nothrow.
> 
> If you can't disable cancellation efficiently (or, for example, if 
that
> requires a mutex! - but I don't see why it would; that should be
> thread-local), then the problem gets more complicated.

I believe efficiency was the rationale they used, if I read the 
snippet correctly.  I don't know enough about the rationale they 
applied to judge this, however.  I need insight from someone who made 
this decision.
 
> > > 2. We don't have a lot of legacy code out there already using 
our
> > library.
> > > If people can't deal with cancellation exceptions, they are 
free to
> > disable
> > > cancellation at the thread entry point, so they always have a 
way
> > out.
> >
> > No, but there's plenty of legacy code that handles exceptions, 
and in
> > ways that may not be compatible with a thread cancellation
> > mechanism.
> 
> You mean, "may catch(...) and fail to rethrow?"

Mostly, yes, though a catch(...) and some operation that assumes 
an "error" occurred could also be considered a bug in this case.  In 
general I'd consider such catch blocks, especially in library code, 
to be a bad idea in any event.  Like I've said before, I'm probably 
worrying too much about this *possible* problem.
 
> > And the "out" may not work.  If they do need
> > cancellation, but some third party library doesn't play nice, 
where's
> > the out?
> 
> What do you mean by "not play nice?"

Eating the exception is a good example of not playing nice.  That's 
why I favor some mechanism that either prevents the user from 
catching the exception, or that insures the exception is rethrown.
 
> > Any way, I think I may have given you the wrong impression.
> > Boost.Threads *WILL* include cancellation.
> 
> I didn't think otherwise. I am just trying to head off exception-
FUD in case
> it's looming in the background. I'm a little obsessive about that, 
sorry!

Well, there is a bit of FUD here.  Exception safety makes me 
nervous.  It's a black art, IMHO, and I often worry that a design 
will wreak havoc in this area.  That won't prevent me from designing 
it any way, it just means I get a little more careful and paranoid.

Bill Kempf