Boost logo

Boost :

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
> > > thread cancelation? It doesn't seem to be mentioned in the
> >
> > 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at