This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]