cancelation handler madness

[Ulrich Drepper <drepper at redhat dot com>]

I've tried to get the cancellation handler problem solved in the last
days but realized today that it isn't possible without a) gcc support,
b) a drastic rewrite which introduces high runtime costs.

The problem is basically that control can leave a function using
return from within an area protected by pthread_cleanup_push/pop.
This leaves a pointer to the record containing the cleanup handler
dangling.

The changes I checked in should catch most problems.  Programs should
not crash anymore.  But in some situations cancellation handlers are
not called.  This is an "improvement" since previously the programs
simply crashed.  There are still problems.  Look at the tst-cancel
test case, the last thread created.  It's pushing to regions, the
second one is left prematurely (and is not executed) and the second
has to be executed because pthread_exit() is called from within the
region.  The problem is that the first handler on the LIFO stack is
the one from the frame we left and the record on the stack is
overwritten by the call to pthread_exit().


There are two (and a half) way out:

a) gcc finally gets exception handling support for C; I don't see me
   writing this anytime soon;

b) we are implementing the push/pop macros as real function calls and
   store the addresses in allocated memory.  This is very slow and I
   don't want to do this;

c) we don't do anything and call people relying on this idiots.  I
   like this best.  There has been one report about this in the whole
   5+ years the library exists.  So we won't offend too many people.
   In addition we can make a macro equivalent to the
   __libc_cleanup_end() macro from libc-lock.h available which simply
   dequeues the record.


I prefer to go with c) until a) gets implemented.  Comments?

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------