[Bug middle-end/54129] emulated __thread variables and pthread_*specific data

["blucia at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129

--- Comment #4 from blucia at gmail dot com 2012-07-30 20:40:31 UTC ---
I don't really see your point.  Where is the code in the destructor for the
__thread variables?  For the pthread_key_create vars, I wrote down what I want
to do to the data, and the destructor does it (in thread_destructor).   

I could write a destructor that doesn't do anything, and just keeps getting
called on my non-NULL thread specific data.   The man page suggests I can
handle the arbitrary order problem by cycling through my destructors up to
PTHREAD_DESTRUCTOR_ITERATIONS times without NULLing any of my data.

>From the man page:
"If, after all the destructors have been called for all non-NULL values with
associated destructors, there are still some non-NULL values with associated
destructors, then the process is repeated.  If, after at least
[PTHREAD_DESTRUCTOR_ITERATIONS] iterations of destructor calls for outstanding
non-NULL values, there are still some non-NULL values with associated
destructors, the implementation stops calling destructors."


The problem is that the current behavior always NULLs out the __thread data on
the first whack.  I want to be able to let the __thread destructor run (in any
order) and NOT zero the data on its first time through (regardless of the
order).  Then, eventually, my pthread_key_create-registered destructor runs,
and accesses the non-zero data.  Later, like the manpage says, my destructors
get called again, and eventually the __thread destructor NULLs out the __thread
data (perhaps based on some global state that indicates things are safe to
delete).