Boost logo

Boost :

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
> >> return the instant (or close to) that a cancellation request is
> >> 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
> threads that never block, as this is generally considered error.
> As an aside, I am in favor of Bill's approach, if we implement
> at all. I would suggest making the exception a private member type
> 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

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