Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 14:56:09

--- In boost_at_y..., Matthew Austern <austern_at_r...> wrote:
> Jens Maurer wrote:
> > 
> > Lee Brown wrote:
> > > I do have one question:  why doesn't Boost.threads seem to 
support
> > > thread cancelation?  It doesn't seem to be mentioned in the 
documentation.
> > 
> > Thread cancelation is difficult to do correctly in a C++ program,
> > because you want to run all the destructors of stack objects of
> > the thread being canceled.
> 
> It's not obvious that that's what you want.  Remember,
> thread cancelation is not a graceful request; it's the moral 
> equivalent of Unix's "kill", maybe even "kill -9".  One valid 
> interpretation is that it ought to mean that the thread should
> cease processing immediately, instead of continuing to do more
> stuff like stack unwinding.

This is not thread cancellation, it's thread termination.  Win32 uses 
termination instead of cancellation, and the dangers that exist are 
so great that MS tells you to never use it, and in practice no one 
does.

Under POSIX, cancellation *DOES* unwind the stack, it's just not a 
C++ stack.  POSIX provides "cleanup handlers" that represent the code 
to be called during the unwinding.  In general, only toy applications 
can survive termination with out stack unwinding.

Kill is not the same as cancellation, BTW.  The OS insures that 
resources are cleaned up after you kill a process, but the same can't 
be done when threads are terminated since the resources may be shared 
between threads.

> This is definitely unsafe, but then, stack unwinding from an
> asynchronous exception isn't exactly safe either.  In either
> cases, about the best you can say is that if you know the
> rules, and you're careful, it's possible to write an
> application that works correctly under those rules.

It's not really ever possible, in real world applications, to use 
thread termination.  (The only way you could safely do this is if a 
thread uses no resources at all, but how many real world examples of 
threads fit this categorization?)  Asynchronous 
cancellations/exceptions *can* be used safely if the thread has the 
ability to turn this form of cancellation on and off and it's turned 
on only during very carefully constructed code segments.  There may 
be a need for this, but it's dangerous enough to warrant VERY careful 
consideration before including this capability.  If it is included, 
it should be used EXTREMELY rarely, and only by those who truly know 
what they are doing.
 
> The question is whether it's a good idea to provide a feature
> that (a) is rarely needed; (b) is unsafe if used carelessly;
> and (c) can be used safely if you're extremely careful.
> 
> (And I hope it doesn't sound like I've biased that question
> toward a "no" answer, because I actually think the answer 
> should usually be "yes".  There's a difference between a 
> feature that's rarely needed and one that's never needed.)

I'm not sure which feature you're talking about here, termination or 
asynchronous cancellation?  I've never seen a case where either 
was "needed", though asynchronous cancellation can give you a 
(possibly minor) performance boost over cooperative cancellation.

Bill Kempf