No. Just no. TLS is just another form of global variables and suffers from the same problems. I.e. the "magic action at a distance" - it's impossible to understand what changes it without checking the whole program.
In particular, transactions, current users and other crap should NEVER go into the context. Pass them explicitly. This applies to Java as well, btw. The test for inclusion into Context should be: "Is this thing used EVERYWHERE?". There are basically two such items in Go: logging and arguably the cancellation tree. Although cancellation is not always needed so it's probably better to be split into its own entity. Alternatively Go can create special-cased TLS for logging use only and leave Context only for cancellation/deadlines. On Wednesday, January 16, 2019 at 1:43:58 PM UTC-8, robert engels wrote: > > I agree with all of those assessments. That’s why I think the “context” > needs to be moved into a language construct. Then the developer is > insulated from most (all) of these problems - that is the “current context” > propagates unless specifically told not to when creating the Go routine. In > almost all cases the context is a single reference so it should be cheap to > propagate. > > If the “context” was a higher level standardized concept, then the > “values” could be typed, so all of the benefits of the Java way - > transactions, logging, “current user”, etc. can all be addressed in a > type-safe manner. > > I’ve stated a few times that a Go routines lack of context (name, purpose, > etc) is a huge problem. It really limits the ability to write very high > performance applications (pinning routines to cores, groups of routines to > CPU’s, marking some routines as “delay GC”, etc.). > > > On Jan 16, 2019, at 3:33 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > > > >> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels <ren...@ix.netcom.com > <javascript:>> wrote: > >> > >> > >> I don’t see the complexity nor the real difference between Go routines > and Threads. In Java TLS is not passed to new threads you need to be > explicit. The ThreadLocal doesn’t allow access to other threads locals > even with thread groups, etc. As far as I understand Go has no concept of > parent Go routine - at least not exposed - so I don’t see the issue. > > > > The difference is that in Java creating a new thread is a relatively > > heavyweight operation. It's not hard, but it's not routine. It's > > reasonable that when creating a new thread you consider how to handle > > any thread local variables. In particular everybody understands that > > the new thread will not have access to any of the thread local > > variables of the parent thread. > > > > In Go new goroutines are started frequently and casually. For > > example, it's routine for people to change a loop computing a list of > > values into a loop that starts a goroutine for each computation. If > > we are using a thread-local context.Context to cancel a goroutine, > > then one would naturally expect all those goroutines to inherit that > > Context value, so that they too will be stopped. If they don't > > inherit it, then we need some extra mechanism to set the thread-local > > Context, and we need to remember to do that. If they do inherit it, > > then we need to think about the cases where they shouldn't inherit it. > > Either way, the operation is sometimes implicit and sometimes > > explicit. That is confusing. > > > > In Java it's not confusing to always make thread-local handling > > explicit. In Go that would be frustrating and awkward. > > > > Ian > > -- 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.
