Re: [boost] Re: first sight

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 16:50:21

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
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.

> 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.

> > 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?"

> 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?"

> 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!

-Dave