Re: first sight

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 
to 
> it.
> 
> You simulate it simply by using a condition.  I'll work on the FAQ 
to 
> 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 
objections:

"[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."