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: Matt Austern <austern at apple dot com>
- Cc: Jason Merrill <jason at redhat 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, Mark Mitchell <mark at codesourcery dot com>, fjh at cs dot mu dot oz dot au, Benjamin Kosnik <bkoz at redhat dot com>, William Kempf <williamkempf at hotmail dot com>
- Date: Tue, 16 Dec 2003 15:05:02 -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>
Matt Austern <austern@apple.com> writes:
> On Dec 16, 2003, at 4:23 AM, David Abrahams wrote:
>
>> Yes, though not directly. Bill Kempf (the Boost.Threads guy)
>> communicated with him and extensively read his writings on the subject
>> before he vaporized. My understanding, from everything I've read, is
>> that David Butenhof believes that *any* asynchronous (forced, not
>> under user control) cancellation model is wrong.
>
> It's quite true that he thinks asynchronous cancellation is
> hard/impossible to use reliably. You can see that in sectiom 5.3.2
> of his very clearly written book.
>
> But we aren't talking about asynchronous cancellation. We're talking
> about deferred cancellation, which means that the thread may be
> cancelled at any cancellation point.
I'm sorry, I was using a shorthand. Let me be clear: a cancellation
exception which propagates from a function which is specified not to
throw is the "moral equivalent" of an async exception. The reason
async exceptions are hard/impossible to use reliably is that
exceptions crop up in regions of code that would normally be nothrow.
> Note that it's possible to temporarily disable thread cancellation in
> critical regions of code. It might be appropriate for glibc and/or
> libstdc++ to do that. On the other hand, we'll have to think carefully
> about standard conformance if we do something like that.
Yeah, that idiom is, again, a library-killer. It requires portable
library authors to be aware of pthreads and insert disablers.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com