Problems are fine. And developer should be able to take care of them. That's what he does. Context is basically a crutch. So are you proposing to make a crutch a language construct?
четверг, 17 января 2019 г., 0:43:58 UTC+3 пользователь robert engels написал: > > 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.
