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

[Nathan Myers <ncm@xxxxxxxxxxx>]

On Fri, Dec 19, 2003 at 08:15:03PM -0500, David Abrahams wrote:
> Ted Baker <baker@xxxxxxxxxx> writes:
> > How are you going to implement this version of
> > read() that raises the exeption?
> >
> > The only way I know is to create a wrapper for the C-language
> > read() function (or the corresponding system call trap), check the
> > return value and if it is negative, throw the exception.
> 
> IIUC, you're still being confused in the same way... but I'll let
> Nathan explain himself because, who knows, maybe it's me that's
> confused after all? 

As I had described the goal, ::read() would never throw an exception.
Library code would never expect, or be prepared to handle, an exception 
from it.  Instead, it would return -1.  It would set errno to EIO or 
ECANCELED or ESOMEDAMNTHINGELSE defined by POSIX.

The simplest way to make this happen would be for the C library to 
do it.  I'm most interested now in discovering and defining semantics 
for synchronous cancellation that make it usable with C++ libraries.  
If we fail, then we are back to the status quo, which is that thread 
cancellation is incompatible with C++ libraries.

Since it apparently isn't yet clear to everybody what I had suggested,
I'll outline it again:

  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.
  C++ library functions that are normally allowed to throw may throw
    a cancellation exception.  (E.g. std::filebuf::overflow().)
  A thread, once cancelled, stays cancelled, regardless of any C++ 
    catch blocks entered or left.
  C++ catch blocks work normally; a cancellation exception may be
    rethrown, or swallowed like any other. 
  In a catch block handling a cancellation exception, functions
    identified as cancellation points work normally.
  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.
  Eventually the inability of the thread to achieve anything leads it
    to top-level code equipped to recognize the cancelled condition as 
    such, and to clean up and die in a controlled way.

I am certain that with enough control over the execution environment,
the above is more or less trivially implementable.

A simpler model would have calling cancellation-point functions from
within a catch block also fail or throw, and the caller be expected
to tolerate the failure or catch (and discard or rethrow) any 
resulting exception.

Nathan Myers
ncm@xxxxxxxxxxx