• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cleanup of pthread_key thread-specific data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cleanup of pthread_key thread-specific data


  • Subject: Re: Cleanup of pthread_key thread-specific data
  • From: Greg Parker <email@hidden>
  • Date: Mon, 24 Sep 2007 16:50:37 -0700

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.

Don't panic. Your code is fine.

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.


-- Greg Parker email@hidden Runtime Wrangler


_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Cleanup of pthread_key thread-specific data
      • From: Sam Vaughan <email@hidden>
  • Prev by Date: Cleanup of pthread_key thread-specific data
  • Next by Date: Re: Cleanup of pthread_key thread-specific data
  • Previous by thread: Cleanup of pthread_key thread-specific data
  • Next by thread: Re: Cleanup of pthread_key thread-specific data
  • Index(es):
    • Date
    • Thread