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

Fergus Henderson fjh at cs.mu.oz.au
Tue Dec 23 09:26:31 UTC 2003


On 22-Dec-2003, Nathan Myers <ncm at cantrip.org> wrote:
> On Tue, Dec 23, 2003 at 02:07:47AM +1100, Fergus Henderson wrote:
> > 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.

That seems fair to me.

> 	- 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.

That seems fair too.

>  	- 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.

Here I don't agree.

Firstly, you should say "a portable C++ library", not "a correct C++
library", since some C/C++ implementations do support throwing C++
exceptions across C code, and I'm sure some correct but not portable C++
code takes advantage of this.

Secondly, and more importantly, I think that allowing this case is
important for language interoperability, not just for C/C++, but also
for interoperability between C++ and other languages (many of which are
implemented via compilation to C).

Posix thread cancellation is, in effect, a mechanism that provides a
limited form of exception handling for C.  It is natural for C implementations
to extend C with more general support for exception handling, both for its
own inherent usefulness and for ease of interoperability with other languages.
For example, both GNU C and Microsoft C have provided C language extensions
for exception handling, and there have been numerous C libraries that
provide support for exception handling -- see for example

	- Costello and Truta's "cexcept" <http://cexcept.sourceforge.net/>

	- Doug Gwyn's "ex" package, available from the cexpect site.

	- Ian Zimmerman's "exc" package, also available via the cexcept site.

	- David Hanson's "except.h", in his book "C Interfaces and
	  Implementations" <http://www.cs.princeton.edu/software/cii/>

	- Bruce W. Bigby's "GEF"
	  <http://home.rochester.rr.com/bigbyofrocny/GEF/GEF.html>

	- Schotland and Petersen's (unnamed?) exception handling library
	  <http://www.on-time.com/index.html?page=ddj0011.htm>,

	- Kaz Kylheku's "KazLib"

	- Symbian EPOC

	- MLib

	- my own "CXCPT" <http://www.cs.mu.oz.au/~fjh/CXCPT/>

There are probably lots more examples.

Given the likelihood of C being extended in this way with some form
of exception handling, it is desirable to make this exception handling
interoperate well with both Posix thread cancellation and C++ exceptions.
This in turn essentially requires that Posix thread cancellation and
C++ exceptions interoperate well with each other.  To my mind that
includes being able to propagate C++ exceptions through cancellation-safe
C code.

When talking about cancellation-safe C code, we should consider that
this may also include exception-safe C code that has been (or will be)
written using a C exception facility that is compatible with and/or
interoperates with Posix thread cancellation.  Currently
pthread_cleanup_push() and pthread_cleanup_pop() are the only
_standardized_ facility for enabling C code to clean up during
stack unwinding.  C exception handling extensions will need to
provide their own facilities for that.  But it seems like a bad idea to have
more than one underlying mechanism for such clean up code; even if
we may be stuck with several interfaces, having them all be implemented
using a single underlying mechanisms seems like the only reasonable way
to get the desired level of interoperability.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



More information about the c++-pthreads mailing list