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

[Nathan Myers]

I object to Matt's characterization of the issues on several levels.  
It misstates expressed concerns, omits others, and assumes its own 
conclusions.  I hope to post in more detail, but I would like to 
address the most glaring problems immediately.

On Tue, Jan 06, 2004 at 11:33:47AM -0800, Matt Austern wrote:
> It's actually pretty hard for me to imagine any model for thread 
> cancellation that's very different from the POSIX.   ...

I presume you mean "different from the POSIX C binding".  One such was 
already detailed here, so you don't need to imagine it, you can just 
go back and read it.  (Since it's a proper subset of the POSIX C binding,
it remains compatible, and could even be back-ported, as an optional
mode, to the C binding.)

> Seems to me that the only real issues for debate are: 
> which functions are cancellation points, 

Any function may be a cancellation point.  If cancellation does not 
cause it to violate its long-documented interface, nothing is broken.  
If it does, then it doesn't matter much which set you choose, you've
broken most libraries anyway.  If you're starting with zero existing
code, all that new code can be written to any interface you make up.

> how a thread can enable and disable cancellation, 

POSIX already defines functions to block and unblock cancellation.  
(They might be called automatically on entry and certain exits from 
catch blocks, though.  That's an interesting discussion.) 

> whether a thread should be allowed to disregard 
> a cancellation request once it has been received, and 

Nobody has proposed allowing a thread to "disregard" cancellation.  
That's a strawman. 

> what kind of cleanup a thread performs before it stops.

This is just where we started.

Really at issue are

  (1) what cancellation is to mean in a C++ context, 

  (2) how to arrange that cancellation does not corrupt the process
      state to the point where it would be pointless not to terminate
      anyway, and

  (3) how to preserve the frankly enormous body of thread-safe code
      already written, deployed, and running for years.

Most presentations here that argue that the POSIX C++ binding cannot
deviate from the POSIX C binding ignore, or carefully avoid, point (2),
and sidestop point (3) with disingenuous historical revisionism.  
They also, as in Matt's, start out assuming much that is as issue.

> My feeling: it's just plain inevitable that a multithreaded program has 
> more functions that might throw than a single-thread program.  Dealing 
> with this is part of what it means to make a program thread-safe.  

This is far from clear, and makes a very poor starting assumption.  We 
have had thread-safe libraries for a long time.  Under one proposed 
model most can simply be declared already "cancellation-safe", without 
changes.  The POSIX C binding people have already abandoned their 
constituents' libraries, but we need not, and indeed we could rescue 
many of those that they have abandoned.

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

Matt, have you confused the cancellation-exception object, which 
would be destroyed by running off the end of a catch block, with the 
thread's cancellation state?

Nathan Myers
ncm at cantrip.org