Re: Ending/canceling/suspending a thread (proposal)

From: williamkempf_at_[hidden]
Date: 2001-08-23 10:14:18

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "Scott McCaskill" <scott_at_m...>
> > You're assuming that use of catch(...) implies that the exception 
will
> > always be re-thrown, but this does not have to be the case and 
indeed a
> > library implementor cannot make that guarantee:
> 
> No, I don't assume anything like this. Not re-throwing in catch
(...) will
> ignore the cancelation request. This is a feature.

That's a bug.  If I ask a thread to cancel it darn well better do 
so.  Being able to catch is fine, being able to stop the cancellation 
is not.  However, there's tricks that can be employed to insure the 
exception is rethrown regardless of what the user codes for his catch
(...).

> If you don't like the feature, you need core language support for a 
special
> exception class that is always re-thrown at the end of the catch
(...)
> clause.

This can be done with out language support.  Alexander (I believe) 
already posted code to this list that accomplishes this.

> > So, thread cancellation is implemented this way, in order for it 
to be
> > robust the user must guarantee that something like the above 
never occurs.
> > If any libraries are being used for which the source is not 
available,
> this
> > isn't possible (unless you have complete trust in the library 
vendor, I
> > suppose, but have fun tracking down _that_ kind of bug!).
> 
> Have fun tracking the other kind of bug where the library you're 
using is
> not exception safe (basic guarantee.) I don't see a problem here. 
Either the
> library you're using works or it doesn't.

Using an exception is going to be problematic with legacy code even 
if you can shore up all the reasonable holes.  That makes me nervous, 
but this will likely be the solution chosen by Boost.Threads in the 
future.

Bill Kempf