On 14 August 2017 at 11:37, Axel Wagner <axel.wagner...@googlemail.com> wrote: > On Mon, Aug 14, 2017 at 12:10 PM, roger peppe <rogpe...@gmail.com> wrote: >> >> Thanks for the blog post. ISTM that you're essentially proposing >> package-scoped thread-local variables. > > > To be clear: I am not proposing anything, really :) I'm just trying to > separate the different concerns people have about context.Value into > inherent (to the problem) and accidental (due to the implementation) ones. > > Your E-Mail is a great example of the kind of thinking I wanted to encourage > :) > >> >> I don't think that's is a good >> fit for Go. Specifically, it doesn't work when channels are used to >> transfer control flow - for example by passing a function through a >> channel to an existing goroutine that calls the function. > > > I haven't thought about that. However, while this would be an interesting > (and potentially confusing) interplay between dynamic and lexical scoping > (employed by closures), I don't think it "doesn't work". A dynamically > scoped variable is bound to the stack it's executing on. It's conceptually > equivalent to sending a func(context.Context) over a channel and calling it > with the context.Context of the receiver. It works just fine.
Yeah, by "doesn't work", I meant that the request context would not propagate as expected in that kind of scenario. That means that we'd be less free to refactor code to use arbitrary goroutines because it might break things. One property that I really appreciate about Go as is is that goroutine use can be an entirely local decision that I can make without worrying about breaking invariants in the larger system. -- 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.
