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. Nevertheless. An interesting point indeed. There are also possible issues the when a goroutine is started in the > context of a request, but actually is nothing to do with that request. > Again, haven't thought of that, interesting point. That would certainly require some working-around if required. There probably would be one of two ways to handle this: Either by not doing it, or by having a kind of "background manager", that forks of a goroutine early on and gets sent background tasks over a channel. The context.Context type might be a little unwieldy, but I believe > that its explicitness is a good thing. > I agree, that explicit passing also has advantages. If a concrete evolution of context is ever actually on the table, that tradeoff certainly needs consideration. Thanks for pointing out these issues :) > > > > On Sat, Aug 12, 2017 at 12:59 AM, Sam Vilain <s...@vilain.net> wrote: > >> > >> On Monday, 7 August 2017 09:06:23 UTC-7, Daniel Theophanes wrote: > >>> > >>> In the projects I've worked on the switch to Context has been a huge > win > >>> all across the board. I think it would be sweet to find an effect way > to > >>> make io.Reader take a context (I often want just that, and when I > really > >>> need it the solution tends to be more inefficient then it could be). > >> > >> > >> Right; the blocking-style interface of io.Reader is a problem here; I > >> didn't really consider this, but my proposal (on its own thread) solves > this > >> problem; readers that know how can read from the sync.Done channel > (which > >> would have to be a 'close on cancel' type channel to allow multiple > >> readers). > >> > >>> > >>> As for Context.Values, I think you are dismissive of the real use-cases > >>> without giving proper weight to them. It can be abused. Just like > >>> go-routines and channels. I'm not saying we can't do better then the > current > >>> implementation, we probably can if the benefit is seen as worth the > cost of > >>> the change. > >> > >> > >> +1. I used the values interface first and found it much better than > >> adding extra parameters to every function, or passing around large > interface > >> types with a bunch of getter methods. > >> > >>> You're saying context is viral. It is. Just like errors are viral. Once > >>> you start returning them you need to propagate them back. Having a > context > >>> argument is saying "this function, or something this function calls may > >>> block for undisclosed amounts of time and we need to know when to stop > >>> blocking and back out." > >> > >> > >> Or "this function wants to log or profile some inner function" or "this > >> function wants to use cached objects read within the same transaction". > >> > >> In my experience, in real server applications you always want these > >> abilities, but few structure their code to include context arguments. > The > >> status quo is that logging is almost always really bad in Go server > >> applications. Caching values read within a transaction is too hard so > >> you'll make more DB calls than necessary. Profiling never covers the > >> tightest loops in your code. This should be easy to add to an existing > >> application without massive refactoring. > >> > >>> > >>> There might be a better way to do ctx (and maybe errors) if the > language > >>> was adjusted; I'm fairly sure go-routine local storage isn't the > answer but > >>> maybe something else would be. Maybe you could create an Arena with a > >>> context and a pattern for returning execution on error and an Arena > could > >>> use multiple go-routines and such. However I think where you would > need to > >>> start is a named real experience building and maintaining a solution > in Go > >>> that gets real use. Then look at it and see where it was painful and > how it > >>> was so. > >> > >> > >> "Goroutine Local Storage" is bad in my opinion because it's effectively > a > >> global, even if it is private to the goroutine. I believe > context.Context > >> is the right pattern, in that values are rolled back as the call stack > >> unwinds, and building it inside the runtime allows performance > optimizations > >> (variable elimination, slot unrolling, combination of context values > into > >> per-scope arenas) which would otherwise be impractical or ugly. > >> > >> Sam > >> > >> -- > >> 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. > > > > > > -- > > 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. > -- 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.
