Boost logo

Boost :

From: petebecker (petebecker_at_[hidden])
Date: 2002-01-14 15:14:43

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > I'm guessing that at least some of the time when people ask for
> thread
> > cancellation, there is some other mechanism which will often
> serve. If
> > that's correct, do we have a write-up of "how to simulate
> > thread-cancellation"? The FAQ entry for cancellation could link
> it.
> You simulate it simply by using a condition. I'll work on the FAQ
> flesh this out.

I'm jumping in in the middle, so if this has already been covered, my
apologies. Asynchronous thread cancellation has enough tricky semantic
side effects that even the Java folks decided it was inappropriate. So
before adding it to boost.threads it's necessary to address their

"[java.lang.Thread.stop, which throws a ThreadDeath exception,] is
inherently unsafe. Stopping a thread with Thread.stop causes it to
unlock all of the monitors that it has locked (as a natural
consequence of the unchecked ThreadDeath exception propagating up the
stack). If any of the objects previously protected by these monitors
were in an inconsistent state, the damaged objects become visible to
other threads, potentially resulting in arbitrary behavior. Many uses
of stop should be replaced by code that simply modifies some variable
to indicate that the target thread should stop running. The target
thread should check this variable regularly, and return from its run
method in an orderly fashion if the variable indicates that it is to
stop running. If the target thread waits for long periods (on a
condition variable, for example), the interrupt method should be used
to interrupt the wait."

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