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

[Nathan Myers]

On Tue, Jan 06, 2004 at 01:29:22PM -0800, Matt Austern 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.

I didn't.  Jason didn't.  Those were the only models posted.

If you want to post a model or a family of models, we can discuss
them too.  Did you have some reason for suggesting that cancellations
might be readily discarded, or did you think somebody else had asked 
for it?

>  (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.

No, the thread remains cancelled.  The difference between that and
the thread actually discarding the cancellation request is that the 
next time a function identified as a cancellation point is called, it 
fails, too.  The cancellation is not lost, or discarded, or ignored; 
it surfaces again and again, indefinitely, as long as the thread fails 
to terminate.  Furthermore, a subsequent (e.g.) filebuf operation 
would actually throw.  If that exception were caught and discarded,
the next would throw again.  Somebody described this as "sticky
cancellation".

Under POSIX C, a thread cancellation handler can continue to run
indefinitely, so you're not describing something fundamentally different 
from the C model.  Likewise, if unwinding were to run catch clauses, 
code in a catch clause could continue to run indefinitely.  

Nathan Myers
ncm at cantrip.org