Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 11:15:53

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> 
> > > Many people object to that sort of design (I don't), but it 
seems
> > to me that
> > > it's the only way to deal with lots of these situations. 
Cooperative
> > > multithreading imposes similar constraints. Well, you can always
> > hijack
> > > operator new() and hope that's called often enough ;^).
> >
> > Generally, the library defines certain functions as "cancellation
> > points".  A CheckForCancellation() is often a "free" cancellation
> > point, but methods known to block a thread for an indeterminate
> > amount of time (such as mutex locking) are generally made
> > cancellation points as well.  This allows the blocking function to
> > return the instant (or close to) that a cancellation request is 
made,
> > instead of having to finish the blocking operation.  This can
> > actually be important to avoid some deadlock situations.
> 
> Sure, that works. The upshot, however, is that you have to rely on 
the
> programmer to call the "right" functions, or the thread will never 
respond
> to cancellation.

Obviously.  That's why this is "cooperative cancellation" ;).

Seriously, though, this is the only safe mechanism in C++, and works 
in nearly every case.  However, there are compelling reasons to 
include asynchronous cancellation, even though it's generally too 
dangerous for casual use.  I've been having this discussion elsewhere 
with Hans Boehm and Matt Austern.  I'm not sure what choice the C++ 
standard should make and will try and do the research required to 
help them make this choice, but I can tell you that Boost.Threads 
won't support asynchronous cancellation.  It's just not an easily 
portable concept.

Bill Kempf