Comments on: Cross Platform Thread Local Storage The problem with a dedicated structure is it add a hard link between that structure and the code. If I want to application specific TLS, I need to change that struct. Our main cases are : error handling variables, per thread allocator. The problem with a dedicated structure is it add a hard link between that structure and the code. If I want to application specific TLS, I need to change that struct.

Our main cases are : error handling variables, per thread allocator.

]]>
By: nicolas/2011/06/17/cross-platform-thread-local-storage/#comment-5821 nicolas Sat, 18 Jun 2011 06:17:28 +0000 Those aspects will be treated in the next part of this article. There exists C++ tricks to solve those problems. llvm::option library is a perfect example. You might have to rely on operator-> and operator*. But you will have to wait for the next part ;-) Those aspects will be treated in the next part of this article. There exists C++ tricks to solve those problems. llvm::option library is a perfect example. You might have to rely on operator-> and operator*. But you will have to wait for the next part ;-)

]]>
By: Anthony Williams/2011/06/17/cross-platform-thread-local-storage/#comment-5763 Anthony Williams Fri, 17 Jun 2011 16:14:49 +0000 Just::Thread library, I found the best way was to resort to a macro: JSS_THREAD_LOCAL. All the nastiness is hidden inside the macro, and at the end you have a variable of the right type, with the right name, which is thread local. (It’s a local reference, initialized with a call to get the value for the current thread).

The next tricky problem is initialization — if you want to allow initialization with anything other than the default constructor then you need some way of specifying the constructor arguments.

]]>