[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