Re: [c++-pthreads] cancellation points report failure

[Nathan Myers <ncm@xxxxxxxxxxx>]

On Sat, Dec 20, 2003 at 06:00:49PM +0100, Alexander Terekhov wrote:
> Nathan Myers wrote:
> [...]
> >  C library and system calls never throw.
> >  In the event of cancellation, cancellation point functions report 
> >    failure via their normal means (e.g. return -1, or NULL), and set 
> >    errno if appropriate.  Blocked calls fail immediately.
> 
> This will essentially break a lot of existing C/C++ code that is 
> cancel-safe and doesn't known how to handle ECANCELED "error" 
> (instead of expected behavior -- exception/unwinding).

I don't know of any "existing C/C++ code that is cancel-safe and doesn't 
known how to handle ECANCELED" errno values.  I don't know of any C++ 
code that expects to field exceptions from C functions.  Uncountably 
many libraries, though, would reasonably be expected to fail (e.g.  
corrupt memory, leak resources) if such an unexpected exception ripped 
through.

Well-written code handles errors, and well-written portable code handles 
unknown 'errno' values sanely.  That is the code that I am trying to 
preserve.  The far tinier fraction of code (0.1%? 0.01%?) of library 
code written to know about asynchronous cancellation exceptions will,
necessarily, be relatively easy to adapt.  

> >  In a catch block handling a cancellation exception, functions
> >    identified as cancellation points work normally.
> 
> They work normally because "When a cancellation request is acted 
> upon, or when a thread calls pthread_exit(), the thread first 
> disables cancellation by setting its cancelability state to 
> PTHREAD_CANCEL_DISABLE and its  cancelability type to 
> PTHREAD_CANCEL_DEFERRED. " And, in plain-C POSIX, "The behavior 
> is undefined if a cancellation cleanup handler or thread-
> specific data destructor routine changes the cancelability 
> state to PTHREAD_CANCEL_ENABLE" (source: TC2).

Details do matter.  The point is to know what you want, first, and
then arrange to make it happen.  It's nice to see that POSIX has
developed vocabulary to describe what we want.

> >  When a cancellation exception is swallowed by a catch block, 
> >    subsequently-called cancellation point functions report failure, 
> >    as before, until another cancellation exception is thrown.
> 
> That's sticky cancel. Not fun if you're using cancel for canceling 
> *jobs* and really want to reuse worker threads (your simply catch 
> and finalize cancel exception, enable cancel again, and continue 
> with next job).

Any top-level code that fields a cancellation exception is equipped to 
unstick it, or do something else appropriate.  But that's none of our 
business.  Our problem is how to propagate the cancellation out of the 
libraries (which don't know what it is) to that top-level code (which 
must), without corrupting memory along the way.

Nathan Myers
ncm@xxxxxxxxxxx