Boost logo

Boost :

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
> > nothrow
> > > guarantee, so they threw up their hands. Well, in fairness I
> > 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
> exception-safety, which operations can throw, and what their
effects may be
> if they do.


> > 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
> > the process they went through to come to the decisions they made,
> > 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
> > as well.
> Sounds good. I'll be the first to admit I'm jumping to conclusions
> their thought process. However, it is clear to me that the decision
> 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
> 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
> nothrow.
> If you can't disable cancellation efficiently (or, for example, if
> 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
> > 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
> > 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,
> > 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,

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at