[HN Gopher] A deep dive into implicit thread-local storage (2018)
       ___________________________________________________________________
        
       A deep dive into implicit thread-local storage (2018)
        
       Author : signa11
       Score  : 43 points
       Date   : 2024-06-02 08:55 UTC (1 days ago)
        
 (HTM) web link (chao-tic.github.io)
 (TXT) w3m dump (chao-tic.github.io)
        
       | o11c wrote:
       | Is "implicit" some sort of standard-ish terminology here? I've
       | always heard it called "native TLS" (as opposed to "library TLS",
       | which has repeatedly been reinvented badly; POSIX's interface is
       | probably the least bad).
        
       | throwawaymaths wrote:
       | Am I just dumb or was this more confusing than helpful. Just tell
       | me where TLS vars go. How tf does an already running thread know
       | that a library has happened and it needs space for new TLS
       | variables?
        
         | o11c wrote:
         | In general, _every_ access to a TLS variable involves a
         | function call, which may allocate. This can only be optimized
         | out in certain models.
         | 
         | Note that the overhead of this is sufficient such that e.g.
         | OpenGL libraries lie and act as if they were loaded at program
         | start even when actually `dlopen`ed, and libc cheats to let
         | them work. Some other libraries try to copy this, but it
         | explodes if there are too many of them.
         | 
         | Async-signal-safety of TLS variables is slightly different but
         | related; only the allocation case is actually unsafe, but it's
         | nontrivial to avoid.
        
       | dang wrote:
       | Related:
       | 
       |  _A Deep Dive into Implicit Thread-Local Storage_ -
       | https://news.ycombinator.com/item?id=18755719 - Dec 2018 (9
       | comments)
        
       ___________________________________________________________________
       (page generated 2024-06-03 23:02 UTC)