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++
- From: Richard Henderson <rth at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 3 May 2003 12:00:15 -0700
- Subject: Re: Interleaving pthread_cleanups in C and C++
- References: <200305030138.h431ceoB003296@minax.codesourcery.com>
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.
Far be it from me to keep you from relenting. ;-)
But what we have now is functional, if less efficient in the
case that the thread *doesn't* cancel.
> (1) Augment the C version of pthread_cleanup_push to push the current
> stack pointer as well as the other information it already pushes.
Since thread cancellation is part of the C library, it can
cheat and know where the stack pointer is within the jmp_buf.
> (2) When an exception is being handled, take advantage of the
> two-phase EH stuff as follows:
>
> - In phase one, figure out what the stack pointer will be after
> control is transferred to the handler.
>
> - If that stack pointer is "older" than the stack pointer in the
> topmost pthread_cleanup_push entry, run cleanups until that is
> no longer true.
>
> - Transfer control to the exception handler.
Forced unwinding isn't two-phase, but the cancellation unwind
handler does get to look at the stack pointer of the frame and
the stack pointer of the topmost pthread_cleanup_push entry to
decide if it should be invoked.
> (3) The function called at thread startup looks like:
Either that or the cancellation unwind handler notices the
top-of-stack condition.
> 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.
It came to our attention that the Eclipse package throws some
10,000 exceptions just while starting up (which revealed a
problem in the construction of libgcj in that the binary search
table the linker constructs was not present).
Or are you trying to make cleanups run whenever there's *any*
exception thrown? I'm not sure I want libgcc or libunwind
having to know that much about libpthread. If that is indeed
your goal I can think of no better solution than try/finally.
r~