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: Richard Henderson <rth at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, Ulrich Drepper <drepper at redhat dot com>, Benjamin Kosnik <bkoz at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, ncm at cantrip dot org, wekempf at cox dot net, fjh at cs dot mu dot oz dot au
- Date: Mon, 15 Dec 2003 18:34:00 -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> <20031215044559.GC3667@redhat.com><u8yler71p.fsf@boost-consulting.com> <20031215221841.GK25423@redhat.com>
Richard Henderson <rth@redhat.com> writes:
> On Mon, Dec 15, 2003 at 12:20:18AM -0500, David Abrahams wrote:
>> > If you don't want to know about pthread_setcancelstate, then you should
>> > not use pthread_cancel either. If you never use pthread_cancel, then
>> > none of this thread is even relevant.
>>
>> I'm a library provider ;-)
>
> Then you have to either have to document that the library is
> not cancelation safe and point users at TFM when they don't
> read it, or expect pthread_cancel to be used and thus call
> pthread_setcancelstate appropriately.
Meaning that I have to know specifically about pthreads. While I
agree that it's a widespread threading standard, I don't think that's
a good precedent to set.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com