Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 11:19:30

--- In boost_at_y..., Mac Murrett <mmurrett_at_v...> wrote:
> On 1/14/02 10:41 AM, "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> >> 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.
> 
> Most modern OSes (NT, Mac OS X, etc.) have a special place in hell 
for
> threads that never block, as this is generally considered error.
> 
> As an aside, I am in favor of Bill's approach, if we implement 
cancellation
> at all.  I would suggest making the exception a private member type 
of
> thread, so that it can only be caught by thread::thread_proxy.

That won't work.

try {
   boost::mutex::scoped_lock lock(mutex);
}
catch (...) {
  // I've caught the exception even though it's a private
  // exception type
}

The best that Boost.Threads can do is insure that even if you catch 
the exception you can't "eat" it.  This may still cause problems with 
some legacy code, but this isn't a good argument against such a 
cancellation mechanism, IMHO.

Bill Kempf