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.
