Re: [c++-pthreads] Restating the Jason model

[Wil Evers <wil@xxxxxxxxxxxxxx>]

Jason Merrill wrote:

> I think this is an appropriate time to restate my proposal.  I think
> there's a fair amount of consensus around these three points:
>
>  * Cancellation is a normal exception.
>  * If a cancellation exception is destroyed, the cancellation request
>    is re-entered, and acted on again at the next cancellation point.

I can't help wondering about the difference between this design and 
Nathan's sticky cancellation model.  It seems to me that in your model, 
I can do something like:

  catch (const cancellation_request&) {
    some_socket.write("Thread cancelled\n");
  }

and expect the write operation to succeed, whereas in Nathan's sticky 
cancellation design, the write operation will throw another 
cancellation_request (unless, of course, I disable cancellation in the 
catch block).  If so, is this intentional?

And what about this one:

  try {
    some_socket.connect("www.ibm.com");
  } catch (const cancellation_request&) {
    throw my_fancy_exception(__FILE__, __LINE__,
      "Cancellation request");
  }

Here, unwinding continues, but the cancellation request is mapped onto 
some other - presumably legacy - exception hierarchy.  Do we really want 
the cancellation request to be re-entered here?

To me, it seems like Nathan's sticky cancellation model uses a 
tried-and-tested design - it simply puts the thread object into an error 
state, causing subsequent operations to fail - whereas your design is 
quite innovative.  I'm not suggesting there is anything wrong with that, 
but I do believe it needs to be justified.

>  * Cancellation is disabled during unwinding.
>
> But there are still some open questions:

[snip]

>  * Should cancellation also be disabled in destructors run during normal
>    execution?  In catch blocks?
>
> IMO, no and no.

This implies a difference in how destructors behave, depending on why 
they are invoked.  If such a difference can be avoided, I think it 
should be: we have Ted Baker's model (destructors always disable 
cancellation), and the other obvious choice is to leave it to the user 
to take the necessary precautions when writing destructors. Good C++ 
programmers already know how to do that.

- Wil