site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com I'm sorry, that wasn't clear from your message, to me at least. <http://people.redhat.com/drepper/tls.pdf> matt. _______________________________________________ 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... On Sep 11, 2005, at 11:12 AM, Gary Byers wrote: As I thought I explained in my message, I'm concerned about perfomance. There's a difference between "having a dedicated register point to TLS" and "having an API for fast access to TLS." An example of the latter is described in: So you would like our toolchain to support the __thread storage class? That is a reasonable request. Note that the implementation details in the paper are not designed to be exploited by application developers, but, rather, as a design for toolchain writers. It was not clear from your initial message that you were interested in this from any other aspect than as an application developer. Though I see now from your web site that your organization does a Common Lisp implementation, so you may fall into the latter category. As you can probably understand, allowing developers to inline the TLS routines greatly limits the ability to provide release-to-release binary compatibility. It would be tantamount to setting the implementation in stone for the lifetime of the ABI. On other platforms, such as Linux, developers are expected to recompile frequently. This is not the case with Mac OS X, so we are limited in the ways we can optimize such routines, and we must make certain concessions to performance to accommodate this requirement. More directly, is the overhead of pthread_getspecific() really that bad? Has it shown up in Shark samples or as a bottleneck in a critical routine for your software? This email sent to site_archiver@lists.apple.com