Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 10:41:57


----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>

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

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk