This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: catch(...) and forced unwind
- From: Richard Henderson <rth at redhat dot com>
- To: David Abrahams <dave at boost-consulting 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: Sun, 14 Dec 2003 20:45:59 -0800
- 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>
On Sat, Dec 13, 2003 at 08:20:15AM -0500, David Abrahams wrote:
> > Basically, all of the C library I/O functions are cancellation points.
>
> Well, I constider that very surprising. It harms the ability to write
> portable code, for reasons explained below.
No. If you're writing a threaded program that cancels code, then
I expect that you've *read* POSIX, and thus realize that if you
want to output bits via write, and you don't want to be canceled,
then you should call pthread_setcancelstate(PTHREAD_CANCEL_DISABLE).
If you havn't done this, then you aren't using the thread API correctly,
and thus are *not* writing portable code.
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.
r~