This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Interleaving pthread_cleanups in C and C++
On Sat, 2003-05-03 at 12:00, Richard Henderson wrote:
> On Fri, May 02, 2003 at 06:38:40PM -0700, Mark Mitchell wrote:
> > Since I resisted try-finally in C, I think I'm on the hook to try to
> > figure out how to make pthread_cleanups work well with combined C/C++
> > programs -- or relent on try-finally as a C extension.
>
>
> But what we have now is functional, if less efficient in the
> case that the thread *doesn't* cancel.
My position is that:
(1) pthread cancellation should be just an ordinary exception -- not
"forced unwinding". That should be reserved for longjmp_unwind.
(2) Any exception passing through C code should run pthread_cleanup_push
cleanups.
I think (1) is the clear consensus position among the C++ people who
have commented.
As for (2), these cleanups would otherwise never be run, which seems
wrong. The semantics of pthread_cleanup_push are that the cleanup is
run when the frame is exited, and exceptions are just another way to do
that.
> > The cost is one word per pthread_cleanup_push and some additional work
> > during exception-handling -- which is not on the fast path.
>
> Careful. Java is notorious for using exception handling as
> a normal control mechanism.
Yes -- put even there it's not on inner loops. In any case, my
suggestion costs a few loads and compares when you're about to transfer
control to handler; not much compared to executing CFA programs, doing
type-matching, etc.
The reason my scheme is better than try-finally in C is that it doesn't
require a language extension. (And, I think it is even possible to get
away without unwind tables for C code on many systems, since you do not
have to actually unwind the stack. But I need to think that through a
little further.)
--
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC