Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 16:32:13

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

> 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.  And the "out" may not work.  If they do need 
cancellation, but some third party library doesn't play nice, where's 
the out?

Any way, I think I may have given you the wrong impression.  
Boost.Threads *WILL* include cancellation.  I was just trying to say 
that I feel confident in the decision to not include cancellation 
from the get-go, but to wait until we can iron out all the obvious 
gotchas.  Again, I think I can say this confidently because Win32 
programmers have done without builtin cancellation since '95. 

> -Dave
> 
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> Interesting point.  Yet more reasons why I don't want to arbitrarily
> add a simple cancellation mechanism.  I'm still learning all of the
> perils of cancellation since my platform doesn't support this
> concept.  I don't think this is a bad decision, after all, a very
> large number of programmers get along quite well with out builtin
> cancellation.  In fact, I often get the impression that the Win32
> programmers are better off with out cancellation, though I do
> understand the desire to include this.
> 
> Bill Kempf
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_y...>
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/

Bill Kempf