This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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 `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |