[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Nathan Myers]

On Mon, Jul 18, 2005 at 02:15:35AM +0300, Peter Dimov wrote:
> Nathan Myers wrote:
> 
> >2. Existing thread-safe and exception-safe C and C++ libraries that do
> >*not* take cancellation into account should still work.
> 
> Even when cancelled?

Of course.  Otherwise what's the point?

> >(This implies
> >that C library calls, including system calls, never throw, by default
> >or during normal operation; likewise for C++ destructors, and C++
> >functions with any throw specification.)
> 
> [...]
> 
> >7. We may assume we can hijack/shadow standard system and library
> >calls and add our own semantics, such as causing them to report
> >failure (perhaps with distinguished ERRNO codes) under circumstances
> >where they would otherwise have succeeded, or (under C cancellation)
> >entered some sort of cleanup mode.  (Scott Lamb has experience in this
> >area.)
> 
> I don't see how this is going to work.
> 
> Consider a pure C program that calls a cancellation point, 'fwrite' for 
> instance. fwrite "throws" - unwinds the stack and calls Posix cleanup 
> handlers.
> 
> Now consider a pure C++ program that calls that same 'fwrite'. It doesn't 
> throw, it signals failure.
> 
> But what does fwrite do in a mixed C/C++ program? "Throw" when called 
> from C code and return failure when called from the C++ part?  What if 
> a C function calls fwrite and is itself called by C++ code? No matter 
> what fwrite does, it will break the C part or the C++ part, or maybe 
> both.

A program has either a C++ main() or a C main().  It never has both.
If main() is C, we have nothing to say about it: POSiX defines 
cancellation for C programs.  If main() is C++, that's what this list
is about.

If you're calling a C-cancellation-safe library from C++, you might 
choose to call it from within one of Wil's cancellation contexts, 
using a mode that matches POSiX C cancellation semantics.  

Regardless, correct code checks for fwrite() failure -- which can 
happen anyway, cancellation or no -- and deals with it.  A library 
function that consistently fails to satisfy its post-conditions must 
eventually return to the C++ context that called it, reporting failure.  
That C++ code, likewise, will fail to secure its own postconditions, 
and also report failure, perhaps by exception.  Whether the exception 
it throws is a cancellation exception or some other doesn't really 
matter much.  What does matter is that control does ultimately return 
to the thread main, which we may presume to understand cancellation, 
and to die cleanly.

Is it possible to write code that doesn't behave well?  Yes, always;
nobody has ever tried to do prevent that, and I don't propose to change 
the policy.  However, it is possible, and universally encouraged, to 
write code that *does* behave well.  There's lots of it, and we can 
provide support for that code.  For the rest, nothing we do can save 
it under any circumstances, so there's no point in talking about it.

Nathan Myers
ncm at codesourcery.com
ncm at cantrip.org