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

[Ted Baker]

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

Just be be clear.  You mean by "thread-safe" that the code
uses mutexes to protect access to shared data, but that it does
not use cancellation state management and cleanup handlers
to protect against thread cancellation.... right?

If so, the only way out seems to be to require that for C++
programs the initial cancellation state of every thread is
*disabled*.

If you do that, then no thread can be cancelled unless it
contains a call to explicitly enable cancellation.

Any application that explicitly enables cancellation either: (1)
has not "been running for years" and so can be expected to take
steps to deal correctly with the potential cancellation exception;
(2) is an old application that already is cancellation-safe using
cancellation-cleanup handlers (which should be executed
transparently if the exception is not handled); (3) was never
thread-safe, and will now get the same behavior as before
(i.e., the exception will not be handled).

> ...have had thread-safe libraries for a long time.  Under one proposed 
> model most can simply be declared already "cancellation-safe", without 
> changes.

You mean the model where all system call return -1 with
errno==ECANCELLED?  Is it safe to assume these libraries are not
making any assumptions about the possible range of causes for
the -1 return?

(Maybe you could point me to two or three examples of
such libraries, so that can look at how system calls are
implemented?)

--Ted