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: Mark Mitchell <mark at codesourcery dot com>
- To: Richard Henderson <rth at redhat 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: 30 Apr 2003 17:39:02 -0700
- Subject: Re: [3.3] Followup to C++ forced unwinding
- Organization: CodeSourcery, LLC
- 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>
On Wed, 2003-04-30 at 17:17, Richard Henderson wrote:
> On Wed, Apr 30, 2003 at 04:50:53PM -0700, Nathan Myers wrote:
> > Any thread can prevent cancellation by putting "while (true);" in
> > a destructor. Once control leaves the catch block, the thread can't
> > do any more externally visible work anyway, because that would touch
> > another cancellation point, which (I assume) would throw again.
>
> Yeah, but you have to work at it to not cancel the thread
> (via exit or longjmp or infinite loop) from a destructor,
> whereas it's easy to forget to rethrow inside a catch(...).
>
> Thus, IMO destructors should be preferred over catch(...)
> for *all* cleanup operations, not just for this cancellation
> question.
I agree. Users should be encouraged to use destructors;
resource-acquisition-as-initialization is a good C++ idiom.
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.
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC