Actually, in many cases they are even more restrictive instance variables. They are not global in any sense.
Furthermore, in most common usage they are read only. In my experience, they are used in very localized settings to avoid construction of non thread safe objects for performance, or they are used by frameworks to handle the context, and the framework manages the scope and lifecycle. In neither case are they confusing or error prone. > On Jan 17, 2019, at 7:56 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > They are not global variables, they are class variables. There’s a huge > difference. > >> On Jan 17, 2019, at 2:32 AM, alex.besogo...@gmail.com wrote: >> >>> On Wednesday, January 16, 2019 at 1:33:57 PM UTC-8, Ian Lance Taylor wrote: >>> In particular everybody understands that the new thread will not have >>> access to any of the thread local >>> variables of the parent thread. >> To be fair, Java does have InheritableThreadLocal variables that are >> automatically shared with downstream threads. >> >> Ironically, it's kinda buggy in Java because a lot of parallel code in Java >> uses thread pools that break InheritableThreadLocals. A similar construct in >> Go would behave much better simply because nobody uses goroutine pools. >> >> Of course, TLS are bad for other reasons (they are basically disguised >> global variables and should be avoided). >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
