This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3] Followup to C++ forced unwinding
- From: Richard Henderson <rth at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Nathan Myers <ncm at cantrip dot org>, Ulrich Drepper <drepper at redhat dot com>, gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Wed, 30 Apr 2003 19:23:25 -0700
- Subject: Re: [3.3] Followup to C++ forced unwinding
- References: <20030430175335.GA18958@twiddle.net> <1051727981.3301.100.camel@minax.codesourcery.com> <20030430210342.GB697@redhat.com> <1051743305.3301.248.camel@minax.codesourcery.com> <20030430230239.GH697@redhat.com> <3EB05952.4050306@redhat.com> <20030430235053.GR19185@tofu.dreamhost.com> <20030501001759.GO697@redhat.com> <1051749542.3301.305.camel@minax.codesourcery.com>
On Wed, Apr 30, 2003 at 05:39:02PM -0700, Mark Mitchell wrote:
> But we shouldn't go silently breaking millions of lines of until-now
> exception-safe ISO-conformant code that happens to use "catch(...)"
> rather than destructors. I'd ever so much rather debug a
> why-didn't-my-thread-go-away bug than a
> why-is-my-data-in-an-inconsistent-state bug.
At this rate we will simply never come to agreement.
(1) I say we cannot enter catch(...) without adding code to do
implicit rethrow because it's *very* likely that your
"exception-safe ISO-conformant code" does not include a
rethrow and is completely unsafe for thread cancellation.
(2) You say we must enter catch(...) because the idiom is so
common that millions of lines will break. Further, you
don't like implicit rethrow.
(3) If we simply abort when crossing catch(...) we will most
definitely cause thread cancellation to be completely
worthless to everyone.
So what are we to do? The best I can offer in good conscience
is adding the implicit rethrow.
r~