--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/eEDlXAVW9vU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
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).
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.
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."
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.
--
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+unsubscribe@googlegroups.com.
Thanks for the blog post. ISTM that you're essentially proposing
package-scoped thread-local variables.
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.
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.
The context.Context type might be a little unwieldy, but I believe
that its explicitness is a good thing.
>> email to golang-nuts+unsubscribe@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+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
--
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...@googlegroups.com.
--
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...@googlegroups.com.