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

[Nathan Myers]

Our goal is to define a binding that is possible, practical, and simple.  
Therefore...

On Tue, Dec 23, 2003 at 02:07:47AM +1100, Fergus Henderson wrote:
> On 22-Dec-2003, Jean-Marc Bourguet <jm at bourguet.org> wrote:
> > I feel confused.  I wonder what is the context of the discussion
> > and especially the constraints or the liberties we assume from
> > an implementation.  Shoult it
> >    - need the collaboration of the pthread library or be implementable
> >      as wrapper around an existing pthread library?
> >    - allow modifications to the C interface visible from C or not?
> >    - allow modifications to the C interface visible from C++ or not?
> 
> I think part of the difficulty is that the problem may be over-constrained.
> Ideally, the solution would
> 
> 	- not require changes to the C pthread library
> 	- not modify the C interface visible from C
> 	- not modify the C interface visible from C++
> 	- never result in a thread cancellation request being ignored
> 	- allow threads to execute arbitrary cleanup code in
> 	  response to a thread cancellation request
> 	- make exception-safe C++ code also safe for (synchronous)
> 	  cancellation
> 	- make cancellation-safe C code also exception-safe,
> 	  and allow propagation of C++ exceptions through cancellation-safe
> 	  C code
> 	- not introduce any new C++ language constructs or semantics
> 	- not introduce any new C language constructs or semantics
> 	- not reduce performance of any existing code
> 	- be simple, easy to use/understand/teach/specifiy/implement, etc.
> 	- probably some other goals that I've accidentally omitted/forgotten
> 
> However, it is almost certainly not possible to achieve all of these
> simultaneously.

I believe that we can achieve our goal if we omit impossible
requirements.  Of the above, I see the following as showstoppers
that must be jettisoned immediately:

 	- not require changes to the C pthread library

  We assume we can adapt the libraries involved as needed, as long as
  our demands are simple to describe and implement.

	- never result in a thread cancellation request being ignored

  This is impossible on its face, as it ultimately depends on users' 
  coding practices.  A reasonable goal would be that simple good coding 
  practices are unlikely to cause cancellation requests to be ignored 
  indefinitely.

 	- make cancellation-safe C code also exception-safe, and 
 	  allow propagation of C++ exceptions through cancellation-safe
 	  C code

  While cancellation-safe C code might exist, in principle, we should 
  not contort our solution to try to accommodate it.  A correct C++ 
  library does not let exceptions escape to C code, so this case is 
  only of academic interest.  We can presume that any C code that is 
  cancellation-safe also handles normal error returns sensibly.

 	- not [ever] reduce performance of any existing code

  Threads necessarily impose inefficiencies.  We can have a goal to
  minimze those.

 	- probably some other goals that I've accidentally omitted/forgotten

  We can burn those bridges when we get to them.

Let's try not to get sidetracked.  The consequence of failure or
excessive delay is that C++, like Ada, will remain incompatible with
any form of thread cancellation.  

Nathan Myers
ncm at cantrip.org