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 <i...@golang.org> wrote: > >> On Wed, Jan 16, 2019 at 7:15 AM Robert Engels <reng...@ix.netcom.com> 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.
