Re: C++ and POSIX Threads Mailing List

[Ted Baker <baker@xxxxxxxxxx>]

I hope the C++ folks can learn something from the work done by the
POSIX Ada binding group, and the Ada language implementation folks,
about ten years ago.

The semantic ramifications of exceptions and thread cancelation
came up during the original P1003.4a ballot, and were the source
of strong objections from the Ada community, including a negative
coordination ballot from the POSIX Ada bindings 1003.5 working
group.  The standard was passed, over these negative ballots.

The net effect is that with Ada one cannot safely use thread
cancelation.  Instead, Ada programmers should use the
language-defined task abort operation, which is integrated with
the handling of exceptions and has well defined semantics.  The
implementations of task abort are rather complicated, because they
cannot rely on much support from the POSIX threads library.

Abort is essentially an asynchronously delivered exception, but it
can only be handled by a special kind of handler, called an
asynchronous select statement.  The latter is called an
asynchronous transfer of control, and works sort of like the
C-language setjmp() and longjmp() from a signal handler; the
differences are that cleanup is done along the way, and the effect
is semantically well defined..  If there is no active
async. select statement, the entire task must be terminated.

Ada requires that propagation of exceptions perform finalization
of all controlled objects, as one "unwinds" the nest of activation
records back to the appropriate handler.

For GNAT we implement abort using a signal.  The signal tells the
task to abort.  The signal handler checks a per-task attribute to
see whether it is currently OK to raise an async. exception.  If
not, the exception will be raised synchronously on exit from the
protected region.  If we are not in a protected region, the signal
handler transfers to control to the nearest handler.  There are
implicitly provided handlers for every scope that requires
finalization.  If there is no explicit (user) handler, the
exception is just re-raised to propagate out to the next handler.

I could say more, since we spent at least three years hashing this
stuff out, first in the ANSI/ISO language standarization area,
then in the POSIX area, and then in the Gnat implemenation. However,
I've learned the hard way that some people don't believe programming
language wisdom transfers between languages.
If you think my input is of any value, plese add me to your
e-mail list.

--Ted

On Thu, Dec 18, 2003 at 02:34:03PM -0800, Mark Mitchell wrote:
> There has been a fair amount of discussion on the GCC mailing list about
> possibe ways of integrating POSIX threads with ISO C++.
> 
> The key question to date has been how to deal with thread cancellation. 
> 
> People have asked questions like:
> 
> * Should cancellation throw an exception?
> 
> * What happens if the exception is caught, and not rethrown?
> 
> * What happens if the exception violates an exception-specification?
> 
> * What should be done about the fact that ISO C++ says that C library
> functions like "printf" never throw exceptions?
>  
> Much of the GCC discussion can be found here:
> 
>   http://gcc.gnu.org/ml/gcc/2003-12/msg00743.html
> 
> However, this issue is not specific to any compiler; it's a general
> question about the interaction between C++ and POSIX threads, and
> perhaps even other threading systems.
> 
> Therefore, we've started a new mailing list for discussing these issues.
> 
> To post messages to the list, send mail to
> c++-pthreads@xxxxxxxxxxxxxxxxx
> 
> To unsubscribe, send mail to:
> c++-pthreads-unsubscribe@xxxxxxxxxxxxxxxx
> 
> The mailing list is archived and available on the web at:
> http://www.codesourcery.com/archives/c++-pthreads/threads.html
> 
> Yours,
> 
> -- 
> Mark Mitchell <mark@xxxxxxxxxxxxxxxx>
> CodeSourcery, LLC