Re: catch(...) and forced unwind

["Zack Weinberg" <zack at codesourcery dot com>]

Jim Wilson <wilson@specifixinc.com> writes:

> Zack Weinberg wrote:
>> Please either explain it again or provide a pointer to your previous
>> explanation, because I never saw it.
>
> The earlier thread was in gcc-patches April 30-May 1.  See for instance
>    http://gcc.gnu.org/ml/gcc-patches/2003-04/msg02284.html
>    http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00016.html
>    http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00055.html
> There are also other relevant messages in this thread.

Thanks.  My summary:

1) Everyone - absolutely everyone - who knows anything about C++
   agrees that the sane semantic is for a catch(...) that does not
   rethrow to intercept and discard a pthread_cancel() operation.

1a) These same people also suspect it would be a good idea for
    pthread_cancel to throw a real live C++ exception, with a name,
    that can be caught explicitly.  But they want to think about that
    a bit more before implementing it.

2) William Kempf (who is one of the people mentioned in (1)) pointed
   to Tru64 UNIX as an example of an operating system that implements
   this semantic, and also gave an argument that this is also the
   correct semantic per POSIX.1-2001.
     [http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00211.html]

3) Ulrich Drepper insists that libpthread cannot implement this
   semantic and still operate correctly in all circumstances.  His
   statement is, I emphasize, one of possibility: he says it can't be
   done, not that he won't do it.

I do not think re-hashing the previous argument is useful.  Instead, I
suggest we call for volunteers to design patches to libgcc and glibc's
libpthread which will implement the desired semantic, and therefore
disprove (3).  If it does turn out to be impossible, fine.  If it
is possible, then we can have an argument about whether the patches
get into glibc, which is at least progress.

zw