This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: catch(...) and forced unwind
- From: David Abrahams <dave at boost-consulting dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Matt Austern <austern at apple dot com>, Ulrich Drepper <drepper at redhat dot com>, gcc at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>, Nathan Myers <ncm at cantrip dot org>, Jakub Jelinek <jakub at redhat dot com>, wekempf at cox dot net, fjh at cs dot mu dot oz dot au, Benjamin Kosnik <bkoz at redhat dot com>, William Kempf <williamkempf at hotmail dot com>
- Date: Wed, 17 Dec 2003 06:22:01 -0500
- Subject: Re: catch(...) and forced unwind
- References: <xypwu91ofvf.fsf@miranda.boston.redhat.com><ud6at1wvg.fsf@boost-consulting.com><xypekv9nr9u.fsf@miranda.boston.redhat.com><u65gkyhv4.fsf@boost-consulting.com><20031214035909.GE2416@tofu.dreamhost.com><xypk74xltaa.fsf@miranda.boston.redhat.com><ullpdlksl.fsf@boost-consulting.com><xyp1xr5lh5q.fsf@miranda.boston.redhat.com><usmjlhryu.fsf@boost-consulting.com><278A5A0A-3001-11D8-8564-00039390D9E0@apple.com><usmjkbkb5.fsf@boost-consulting.com><0BB52C3C-3009-11D8-8564-00039390D9E0@apple.com><ud6aobfgy.fsf@boost-consulting.com><A156A7B0-3012-11D8-8564-00039390D9E0@apple.com><uu1409v32.fsf@boost-consulting.com><xypd6aoi0zz.fsf@miranda.boston.redhat.com><1071632782.3793.114.camel@minax.codesourcery.com>
Mark Mitchell <mark@codesourcery.com> writes:
> (3) The thread_cancellation objects contain a reference count; copying
> the object increments the reference count and destroying the object
> decrements the reference count. If the reference count goes to zero (as
> would happen when the exception is caught and not rethrown) the thread
> is uncancelled.
If "uncancelled" doesn't mean "re-deferred", I don't see the point of
the reference count. How is the "uncancelled" case different from
the one where a copy of the thread_cancellation object is kept alive
indefinitely, i.e.
catch (posix::thread_cancellation& x)
{
some_stack.push(new (nothrow) thread_cancellation(x));
}
?
> With these changes, library designers can still say "catch all
> exceptions", but they can also say "catch all exceptions except thread
> cancellation".
How? You must mean something like:
try { ... }
catch (posix::thread_cancellation&) { throw; }
catch (...) {
... // here
}
That's still catching thread cancellation, so I would choose a
different description if that's what you meant.
> It may be that catching all exceptions is a bad idea,
> but that is up to the library designer.
>
> These changes are a pure extension to POSIX threads; they do not break
> any existing POSIX threads code.
>
> These changes are not quite a pure extension to standard C++; the C++
> standard prohibits C library functions from throwing exceptions, so, for
> example, "printf" cannot throw an exception.
I'm not convinced there's a better solution, but it seems to me that
this could be a disaster for the ability to freely use C++ libraries
in threads without knowing something about their implementations.
Is it worth considering adding a mechanism which turns off
cancellation exceptions during unwinding? I realize it's a
half-measure, but at least it would prevent some printf logging code
from sending us to terminate.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com