From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 10:00:26
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:05 PM 1/15/2002, bill_kempf wrote:
> >Cooperative/deferred cancelation most certainly can be done safely
> >and effectively in C++. Doing so portably puts a few constraints
> >us. For instance, Boost.Threads is going to have to use an actual
> >C++ exception here (I believe), while the standard could just use
> >a "kissing cousin" to the exception (i.e. the standard could make
> >type non-catchable).
> To add Boost.Threads (or any other threading library) to the C++
> will require a number of additions to the standard document. I
> is either surprising or upsetting to most committee members.
> AFAIK, however, the current Boost.Threads does not require changes
> current C++ compilers which already support native platform threads.
> That makes it a MUCH easier to sell to the compiler vendors, who
> represented on the committee. They can see that it already works,
> already works with their compiler. It also means users can benefit
> rather than having to wait for years.
> Likewise, there are strong advantages if it is possible to
> cooperative/deferred cancellation via an actual C++ exception.
> don't have to be changed. We can show that it works. Can be used
> If the wording in the standard gives the implementors leeway to
> a more efficient "kissing cousin", fine. But it is a huge win if
> moderately efficient portable (at least between compilers on the
> platform) implementation can be done in standard C++.
Agreed, and the final decision is, of course, up to the committee.
I'm just trying to "feel out" the pros and cons of using an actual
exception, which can be caught in a catch(...) block. If there are
compelling reasons to want the "exception" to be non-catchable then I
can present these reasons to the committee and they can decide
whether or not it's worth requiring a language change to allow for
this "kissing cousin".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk