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

[Matt Austern]

On Dec 29, 2003, at 5:58 PM, Nathan Myers wrote:

> On Mon, Dec 29, 2003 at 03:28:17PM -0800, Richard Henderson wrote:
>> On Sat, Dec 27, 2003 at 08:54:06PM -0800, Nathan Myers wrote:
>>> Do you _really_ see breaking just about every existing thread-safe
>>> library as a minor change?
>>
>> Yes.  Primarily because I disagree that changing the throw status
>> of printf will have this effect.
>
> Have you ever coded C++?  Exception-safe code depends on knowing
> where exceptions may occur.  While it is very rare that code depends
> on returned results from ::printf, other calls have rather more
> complicated result semantics.

I agree that we shouldn't rule out the idea of changing POSIX
functions' interfaces.  As you say, the POSIX specification
deliberately chose not to take C++ into account.  We don't have
that luxury.  (Digression: one other question that POSIX doesn't
answer, but that we do have to answer, is what namespace these
functions go in.  Most people have assumed that not saying
anything means they go into the global namespace, but that's
not logically right.  Not saying anything means not saying
anything.)

I'm not so sure I agree with you that declaring them nothrow,
and representing thread cancellation as a new kind of error
code, is a good idea.  Remember, the whole idea of thread
cancellation is that the thread is supposed to *stop*.
Synchronous cancellation means it doesn't stop just anywhere,
and POSIX puts in some features to give programmers a bit more
control (temporarily disabling cancellation, registering cleanup
handlers, and so on), but the basic idea is still there that
thread cancellation is an urgent request.

You're right that C++ code that uses printf, and that doesn't
take cancellation into account, won't function properly in the
presence of thread cancellation.  But I claim that the same is
true under your scheme: a library that doesn't rigorously check
return codes, and that doesn't introduce its own cancellation-
handing framework using those return codes, also won't function
properly in your scheme.  If anything, I think it'll be easier
to fix naive code under the exception-throwing scheme than under
the error return scheme.

Maybe we should start by tracing through the logic we originally
used that led us to think that thread cancellation had something
to do with exceptions.  Our reasoning may have been wrong, but
at least it should be taken into account.

			--Matt