[SPAM] - Re: [c++-pthreads] Re: FW: RE: Re: I'm Lost - Email found in subject

[Ted Baker]

> As far as I remember, Ulrich is the only person who has really argued
> that it is unambiguously wrong to consider the situation in which a
> thread catches a cancellation exception. -- Mark Mitchell

This is one of the points where (*IF* this "study group" recommends to PASC that
a project be started, and once the actual standard working group gets down to
business) the POSIX C++ API group will need to make a choice between
compatibility with the POSIX C API and "doing the right thing" from their own
point of view.

A core issue will be the canonical implementation model.  I see two
approaches:

(A) Limit required semantics to what can be implemented using the POSIX C API,
in C++-specific libraries, possibly with some help from the C++ compiler.

(B) Create new semantics, which go beyond what can be done using the
POSIX C API. 

When it comes to thread cancellation, there is an existing C
library mechanism.  You either build on it and limit your choices
to what that permits (A), or you build something new (B).  If (B)
it will not be suitable for mixed C/C++ programs unless you can
think of a unified mutually compatible underlying implementation
mechanism and persuade the maintainer of the C library to do the
work needed to make them interoperable.

As this pertains to the question of whether thread cancellation
can be handled, option (A) must be implementable using a library
that supports the POSIX C API (and does no know about C++).

The POSIX C API presumes that once cancellation of a thread
begins it will progress through to termination of the thread.  For
example, the description of "acting on" thread cancellation says
that "The cancelability state shall remain set to
PTHREAD_CANCEL_DISABLE until the thread has terminated."  In
particular, it seems to me that the code of cancellation handlers
is permitted to assume that it will run to completion, all the way
out to the point of termination.

It seems to me that if you try to layer a C++ API on top of the C
API, this limitation will catch you.  That is, if the C++ layer
allows thread cancellation to be handled (and resume execution of
the thread) there is no way that you could use the C API directly
to later cancel the thread (again), since from that point on the C
API sees that cancellation is disabled.

This seems to be a special case of a more general problem, which
will come up with every C library function that is a potential
cancellation point.  If a C++ application or library calls such a
C library function, the C function will not know about C++
exceptions, and so will invoke some C-specific mechanism to
implement the thread cancellation.  In particular, it will
probably call a C runtime library routine that starts walking the
stack, finding cancelation handlers, and executing them.

How does this get transferred into a C++ exception.  I see a few options
e.g.,

(1) You put a wrapper around every cancellation-point function, which
    installs its own cleanup handler, and the cleanup handler raises the
    C++ exception instead of returning in the normal way.  A problem:
    this poentially violates invariants of the C cleanup handler model,
    since in C handlers must always return and then the thread must terminate.
    To make sure nothing breaks you need to get the C library implementor on board
    with the new feature.  He/she will want to know how much rewriting of C library
    code will this take?   Will there be a perforamance hit for C applications?
    
(2) You roll your own C++ version of the entire library function, which calls
    a C++ runtime routine to implement thread cancellation.  The C thread
    cancellation and the C++ thread cancellation are unrelated and do not
    interoperate.  You don't need any cooperation from the C library
    implementor, but if you have a program that tries to use the two API's
    at once (maybe in different libraries) you sometimes get the C handlers
    and sometimes the C++, and maybe everthing crashes as one kind of exception
    tries to propagate into the scope of the other.

Maybe other readers will suggest more stragies.

In any case, I dare say you need to first decide the degree to
which interoperability of C and C++ code is important enough to
sacrifice other functional and aesthetic considerations.  You then
need to come up with an implementation model that provides that
supports that level of interoperability without excessive costs
in modification to working C and C++ standard language libraries
and the standard POSIX API libraries.

--Ted