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

[Wil Evers]

Nathan Myers wrote:

> On Tue, Jan 06, 2004 at 01:29:22PM -0800, Matt Austern wrote:

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

OK, that sounds reasonable - the 'sticky cancellation' concept provides 
some guarantee that a thread that ignores or discards a cancellation 
request will be reminded later.

However, it seems to me that the idea of simply having system calls 
defined as cancellation points fail until the cancelled thread has 
finished its job is just too crude.

In particular, it would prevent the thread being cancelled from doing 
any I/O at all, even when that I/O is part of the cleanup the thread is 
supposed to perform in handling the cancellation request.

Your ETHREADCANCELLED proposal relies on higher-level C++ code to turn 
this errno value into some kind of thread_cancelled exception at a point 
where such an exception can be reasonably expected.  This seems to 
suggest that the underlying machinery in the system call interface 
library will be unaware of the actual steps the thread in question takes 
  in honoring the cancellation request: it would simply report that 
cancellation has been requested, leaving it to higher-level code to take 
appropriate action.

If that is the case, then how do we stop the ETHREADCANCELLED error from 
resurfacing - possibly triggering a C++ exception or even a call to 
terminate() - while the thread is busy cleaning up?

- Wil