This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: exception handling predicament
On Fri, Aug 19, 2011 at 07:12:52AM -0700, David Miller wrote:
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Fri, 19 Aug 2011 07:07:28 -0700
>
> > Is this related to:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48338
>
> I think that commit you triaged this GCC bug to is just exposing the
> issue and not the true cause.
>
> You may want to mention my analysis in that bug report.
>
> The big question is whether __cleanup__ can be used when exceptions
> (and thus the unwind) could be triggerd asynchronously. I think it is
> not designed to do so, and therefore __cleanup__ cannot be used in
> this aio_suspend.c situation.
Most of glibc doesn't allow pthread_cancel unwidning to occur asynchronously
though, only pthread_setcanceltype and the syscalls code (usually in
assembly) and other lowlevel code. You aren't allowed to call most of glibc
functions with PTHREAD_CANCEL_ASYNCHRONOUS cancel type, and usually a
cancellation point doesn't occur in the same function as cleanup. The
cleanup attribute has been designed for what glibc uses it for, so it
certainly should be used for that.
If aio_suspend.c is the only spot where a cancellation point happens in the
same function as corresponding cleanups, then IMHO the best fix is just to
make sure it is in a different function (with noinline attribute, not marked
as nothrow), which will be the cancellation point. glibc is built with
-fasynchronous-unwind-tables, so it isn't about .eh_frame, just about
.gcc_except_table.
Jakub