Re: Masked cancellation mode draft

[Rich Felker <dalias@libc.org>]

On Sun, Feb 22, 2015 at 06:51:47PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-02-21 22:24:53 -0500]:
> > When the cancellation state is set to MASKED, the first cancellation
> > point (other than close, which is special) called with cancellation
> > pending, or which has a cancellation request arrive while it's
> > blocking, returns with an error of ECANCELED, and sets the
> > cancellation state to DISABLE.
> > 
> > Even code which was not specifically written to be cancellation-aware
> > is compatible with this behavior. As long as it is responding to
> > errors, it will see the error, but will have the full repertoire of
> > standard functions available to use while cleaning up and returning
> > after the error. If the error is ignored, cancellation will be
> > delayed, but the behavior is no worse than what could already happen
> > from ignoring errors.
> 
> so it works like a special signal that only acts at blocking calls

And unlike portable signal-based approaches, it lacks the race
conditions and global state.

> since the thread is not forcefully killed, only notified about the
> cancellation, the cleanup mechanism is under the control of the
> programmer
> 
> this seems like a relevant approach to c11 and c++11 which currently
> lack any way to safely cancel blocking threads

Yes.

> the only difficulty i see is that posix has a lot of cancellation
> points (some of which are optional) so code that wants to be
> 'masked cancellation safe' should properly do the error handling
> at a lot of places (eg some stdio functions like printf maybe
> cancellation points and usually not checked for errors directly
> only in aggregate through ferror)
> 
> if i understood correctly code that does not want to immediately
> act upon masked cancellation (only at specific calls) should reset
> the cancellation state with
> 
>   pthread_setcancelstate(PTHREAD_CANCEL_MASKED, 0)

Library code would do this but with &old_cs rather than 0, then
restore the state before exiting. It it wants to actually behave like
a POSIX cancellation point, it would do something like:

    pthread_setcancelstate(old_cs, 0)
    if (was_canceled) {
        pthread_testcancel();
        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, 0);
    }

Then, if old_cs was PTHREAD_CANCEL_ENABLE, the pthread_testcancel will
cause cancellation to be acted upon and the caller's cleanup handlers
to run. If old_cs was PTHREAD_CANCEL_MASKED, then pthread_testcancel
will do nothing and the subsequent call to set PTHREAD_CANCEL_DISABLE
will prevent further ECANCELED from happening (since your caller is
going to get its ECANCELED error from the function that's about to
return).

> and then cancellation is deferred until the next cancellation point.
> 
> another issue is that pthread_testcancel() has no return value so it
> cannot be used for non-blocking testing of masked cancel.

Indeed, I noticed that. There are stupid ways to test but they're not
terribly efficient: lots of cancellation points have timeouts that can
be zero, but most of them are likely to result in a syscall if
cancellation is not already pending.

Rich