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 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~


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