site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Don't panic. Your code is fine. -- Greg Parker gparker@apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Sam Vaughan wrote: If my interpretation of the man page is correct, my code would call free() PTHREAD_DESTRUCTOR_ITERATIONS times in a row for each thread's buffer pointer when the threads are destroyed. This would obviously be bad. To fix it I'd need to have my own destructor function that knows the key and calls pthread_setspecific to clear the thread's key value after calling free() itself. I wrote a little program to see what behaviour really occurs on 10.4.10 and found that the key destructor is actually only called once, even if it doesn't clear the key value itself. libc erases the thread-specific data before calling the destructor once. This is the correct behavior. You don't have to erase it yourself. The outer destructor loop is to handle the case where a thread- specific destructor itself sets some thread-specific value (perhaps for a new key, or a non-NULL value for an existing key that's already had its destructor called once). The next iteration of the loop will destroy that new value. If the thread-specific destructors are still inserting new thread-specific values after PTHREAD_DESTRUCTOR_ITERATIONS then libc just gives up and kills the thread, leaking whatever values are left. For example: your key's destructor is called once. Then some other destructor is called, and that destructor calls into your code. Your code sees that your thread-specific value is now NULL, and creates a new one. Next time through the destructor loop, your key's destructor will be called again to free this second value. This email sent to site_archiver@lists.apple.com