> 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.
