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: Nathan Myers <ncm at cantrip dot org>
- To: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>,Mark Mitchell <mark at codesourcery dot com>,Richard Henderson <rth at redhat dot com>,Ulrich Drepper <drepper at redhat dot com>, gcc-patches at gcc dot gnu dot org,jason at redhat dot com
- Date: Fri, 2 May 2003 09:09:20 -0700
- Subject: Re: [3.3] Followup to C++ forced unwinding
- References: <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> <m3fznxo5a3.fsf@uniton.integrable-solutions.net> <20030502152057.GB21126@ceres.cs.mu.oz.au>
On Sat, May 03, 2003 at 01:20:57AM +1000, Fergus Henderson wrote:
> > | 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.
> >
> > strongly seconded.
>
> I agree that ignoring "catch(...)" handlers for cancels is not going to fly.
> I agree about which bug I'd prefer to debug.
>
> But my intuition is that I think that very few of those million lines
> of until-now exception-safe ISO-conformant code would break from an
> implicit rethrow if/when a cancel got swallowed -- I think a lot more
> would break from an implicit terminate() in the same situation.
Reams of code would be broken in either case. How much in each
is debatable, and moot.
If code is to be broken, it should be broken as loudly as possible.
At compile time, if possible. Automatically re-throwing violates
that principle.
It's best just not to break the code at all, and that is also easily
implementable. Apparently all it needs is to give the cancelled
thread defined semantics for all plausible operations. That also
ought to be easy.
Nobody has posted any reason why the state of a cancelled thread
should be so corrupted, beyond "read the code", without any details
even of where this code is. Can somebody please post the code or
a URL, and an explanation of why it must be so?
Thus far, nobody has more than hinted at any rationally sound reason
for breaking all exception-safe libraries used in thread contexts.
We really should see the details before this goes any farther.
Nathan Myers
ncm@cantrip.org