[c++-pthreads] Re: C++ and posix threads

[Nathan Myers]

Richard, please suspend judgment and read carefully.

On Mon, Dec 29, 2003 at 09:07:55PM -0800, Richard Henderson wrote:
> On Mon, Dec 29, 2003 at 05:58:08PM -0800, Nathan Myers wrote:
> > 
> > Richard, all these "ZERO uptake" remarks make it very hard to discuss 
> > design decisions calmly.  [...]
> 
> If you think I mean just Uli, then you're wrong.  I mean any vendor.

Have you actually asked all all these vendors?  I suspect you'd find 
that most would have preferred the option to offer _only_ error-return 
semantics, and not be obliged to implement unwinding at all.  The
error-return semantics are certainly easy to provide.

Imagine, for the sake of discussion only, a single new pthread call, 
e.g. pthread_c10n_points_fail().  After it is called, C cancellation 
points, when cancelled, do not unwind the stack, they just return EOF, 
or -1, or 0, as appropriate, and maybe set errno.   Would ordinary 
well-written, thread-safe code break?  No.  Would (those few) libraries 
that have already been modified to be "cancellation-safe" fail?  No.  
Would cancelled threads fail to die?  No more so than they might with 
C-style unwind semantics.  Might some cancelled threads take a little 
longer to die?  Maybe, but no time limits are defined in any case.

> I also, personally, think that having different semantics for
> bleeding system calls between C and C++ is the worst idea ever.

No C++ programmer would object to allowing C programs to run with 
error-return semantics.  Furthermore, many of the people who maintain 
C programs would welcome the opportunity to exercise those semantics, 
and not be obliged to rewrite all their libraries.

You write as if we are asking for something radical, when in fact we 
simply want well-established public interfaces to continue honoring 
the same semantics they have always documented.  (Adding a new reason
they might fail doesn't violate the documented semantics, because 
they are documented as perhaps failing for reasons beyond those
listed.)  What is radical is to change system calls' semantics without 
changing their names.

Good code has to handle ordinary failures anyway.  Ordinary failures
exercise those handlers.  Similarly, in C++, destructors have to be 
run anyway.  Running them during exception handling doesn't add extra 
risk.  Making cancellation exercise that same code, whether normal 
failure handling blocks or destructors and catch clauses, is likewise 
pretty safe.  Coding a whole separate apparatus for cancellation that 
is otherwise never executed, though, is fundamentally risky.  
Unexercised code rots.

> If you want to automatically disable cancelation while destructors
> are running, that would be fine.  Small changes to the exception
> support code in libstdc++ could do that.

I don't doubt that it would be easy to support such a change.  
It might be necessary, but it would not suffice.

> Beyond that, I have no idea what you think the problem is with
> system calls throwing exceptions, nor what you hope to achieve
> with ETHREADCANCEL.

I will explain again.

I am certain that (under other circumstances) you, Richard, can easily
recognize how changing the semantics defined at an interface breaks 
code written to the old definition.  Earlier, I posted a code example 
to illustrate it.  I am also certain that you can easily understand 
why people avoid changing library code unnecessarily, particularly 
in libraries they don't control.  I am at a loss to understand why 
you seem unable or unwilling to apply that understanding in this 
case.  Can you enlighten us?

Many of us see it as neither necessary nor responsible to break 
the thousands of well-written libraries that have been deployed 
and running for years on millions of systems, in programs linked 
with "-lpthread".  Nothing in the goal of supporting thread 
cancellation seems to require violating ISO-standard language 
semantics.  Our goal is to continue to use the same libraries we 
have been using, unchanged, and to have them support reasonable 
cancellation semantics just as they are.  As it happens, that is 
technically easy to achieve. 

As it is, cancellation is not compatible with g++.  Changing language 
semantics in g++, or demanding changes in third-party libraries, is 
certain not to fix that.  Just suspending cancellation in catch 
blocks isn't sufficient to fix it.  Our needs are simple, and 
neither remarkable, radical, nor unreasoned.  I don't understand the 
hostility they evoke.

Nathan Myers
ncm at cantrip.org