Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 10:18:36

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> Boy, I love it when I read someone's post who really understands
> exception-safety :^)
> 
> ----- Original Message -----
> From: "Tom Becker" <voidampersand_at_f...>
> 
> > Throwing an exception will do the clean up. But many thread
> > implementations don't provide a way to interrupt a thread and 
force
> > it to execute code (such as a throw statement) that isn't already
> > compiled into the thread at that point.
> 
> Good thing, too!
> 
> >  Also, exception-safe code
> > depends on knowing that certain ranges of code, such as simple
> > copying a pointer, can never throw. Interrupting a thread can be 
safe
> > only if the cancellation exception is thrown from a point where 
the
> > code expects some exception may be thrown.
> 
> Exactly!
> 
> > Since the runtime can't
> > read the mind of the programmer, this means the programmer must
> > supply hints. The simplest approach is for the thread to 
occasionally
> > call a CheckForCancellation() function that checks a variable and
> > conditionally throws a cancellation exception. The thread won't 
get
> > canceled right away, but at least it will be canceled at a safe 
time.
> 
> 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.

Bill Kempf