[c++-pthreads] What are the real issues?

[Jason Merrill]

On Tue, 6 Jan 2004 13:29:22 -0800, Matt Austern <austern at apple.com> wrote:

> On Jan 6, 2004, at 1:12 PM, Nathan Myers wrote:
>
>>> ... I think the really fundamental issue is whether a thread
>>> should be allowed to receive a cancellation request, start to do some
>>> work as a result of the request, and then decide that it doesn't want
>>> to be cancelled.
>>
>> Nobody has proposed any such thing.
>
> Really?  I think that you and I both did.
>   (1) My proposal (which may or may not be a good idea, but which
>         I think should be considered) is that cancellation could be
>         represented by an ordinary exception instead of by a special
>         kind of exception with forced unwinding semantics.  This would
>         allow a thread to catch the exception, set a flag, swallow the
>         exception, and continue executing.  that is, it would allow a
>         thread to receive and act on a cancellation request but for it not
>         to be canceled.

My proposal is that it acts as a normal exception, but that

 * If a cancellation exception is destroyed, the cancellation request
   is re-entered, and acted on again at the next cancellation point.

So the cancellation request never goes away until the thread does.

>   (2) Your proposal is that the POSIX functions that are currently
>         described as cancellation points shouldn't raise any kind of
>         exception and shouldn't cause the thread to stop executing,
>         but should instead return an error code.  Again, this would allow
>         a thread to note the error return, check errno to see if it's
>         ETHREADCANCELED, set a flag as a result of having received
>         the cancelation request, and continue executing.  Again, your
>         proposal would allow a thread to receive and act on a cancellation
>         request without being canceled.

You are assuming that this would only happen for the first call to a
cancellation point, which doesn't seem to be what Nathan had in mind.
Here's his proposal 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.

Jason