[c++-pthreads] concrete library-code example

[Nathan Myers]

On Wed, Dec 24, 2003 at 11:55:59PM -0500, Jason Merrill wrote:
> >
> >   int affect_world(struct state* s)
> >   {
> >     int result;
> >     violate_invariants_or_claim_resources(s);
> >     result = c_function_or_system_call(s->member);
> >     if (result < 0) {
> >       clean_up(s, result);
> >       return result;
> >     }
> >     act_on_result(s, result);
> >     restore_invariants_and_release_resources(s);
> >     return 0;
> >   }
> >
> > This pattern is extremely common in both C and C++ libraries.
> > If  read() were to throw (or to "just ... not return"), the 
> > program state would be corrupted.  A redefinition of
> > c_function_or_system_call semantics that breaks this code breaks 
> > many thousands of existing thread-safe C and C++ libraries.
> 
> This is not cancellation-safe C under the current POSIX standard, if
> c_function_or_system_call is a cancellation point.  If it is, cleanups
> are run and the thread is terminated.  To be truly thread-safe, the
> user must use pthread_cleanup_push/pop so that the resources are
> released on  cancellation.

I think that is what I said.  It was thread-safe code until the 
semantics of calls it uses changed without changing the names.  
What was good code is now broken, in a POSIX C thread-cancellation 
environment.  

> Implementing cancellation by throwing an exception has no effect on
> the thread-safety of this code.

In other words, because (under the C binding) this code has already 
been broken, throwing exceptions through it won't break it any further.

However, we're not talking about the C binding here.  This list is for 
discussion of a C++ binding, which need not be so procrustean as the
C binding.
 
> > Jason, do you not consider those libraries worth preserving?
> 
> No, they're already broken.

You answered the question with reference to the C binding.

Defining a C++ binding is the purpose of this list.  With an 
appropriately-defined C++ binding, those libraries need not be broken 
*when linked as part of a C++ program*.  In other words, you, as a C++ 
implementer, have the power to choose whether to preserve or to break 
those C and C++ libraries, regardless of what has been decided for
the C binding.  (C++ coders would certainly choose to preserve them, 
but it seems that no C++ coders are in a position to do more than try 
to persuade you.)  

So, I ask the question again, but in reference to the C++ binding
that we are working on here.  What would breaking all those thousands
of existing libraries buy us?

Nathan Myers
ncm at cantrip.org