Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Fergus Henderson <fjh@xxxxxxxxxxx> writes:

> When a thread gets a cancellation request, the first
> cancellation point encountered thereafter will act on that request
> (by unwinding the stack, or in Nathan's model by returning an error
> return status and setting errno = ECANCELLED).  If another
> cancellation point is encountered after that, and there has not
> been another cancellation request, then the cancellation point
> will normally not have any effect.
>
> With "sticky" cancels, after a cancellation request,
> *every* subsequent cancellation point will act on the cancel
> (by unwinding the stack, or failing with ECANCELLED).
>
> "stick" cancels make it difficult/impossible to clean up properly,
> since cleaning up may involve doing I/O, and in particular by calling
> functions that Posix specifies are cancellation points.  These functions
> will fail to do the I/O, because they will instead attempt to act on
> the cancellation again (i.e. re-raising the cancellation exception
> or failing with ECANCELLED).

OK, thanks for the explanation.  Sounds like an argument for Jason's
exceptions that re-assert cancel when they're destroyed.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com