For the general interest: I wrote up my thoughts on this in a lengthy blog post: Why context.Value matters and how to improve it <https://blog.merovius.de/2017/08/14/why-context-value-matters-and-how-to-improve-it.html> In particular, I sketch a design how context.Value could be made a language-level feature removing most of the disadvantages often ascribed to it. With this I am trying to put a more concrete face to the ideas behind the suggestion of using goroutine-local storage or the like to solve the issues. While I can't speak for others, I see similar ideas hinted at in this thread.
I hope this can help to steer the discussion into the more helpful underlying questions, instead of getting hung up on details of the current implementation. 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.
