I agree with Dave Cheney and Michal Strba that Context should not be used 
for storage of any kind and only serve the purpose of cancelation.

In effect, the original purpose of Context, I think, was avoiding cascading 
failure in chains of  *network* calls, where the result of one call would 
be used as argument to the next call. In effect, a kill switch on the whole 

A deeper analysis of this feature makes me think that this is not so much 
about goroutines (hence not so much about thread local storage) as much as 
network failures.

And finally, I think the last thing anybody wants is to pollute the whole 
stdlib with Contexts. 

To me, given these requirements, context should become embedded in all 
network functions, just like a timeout is. 

Only difference, when creating a network function (client or server) one 
would (optionally) call SetContextName("MyContext") on it (I think the 
namespace suggestion from plan 9 is excellent), so a chain of network calls 
would belong to the same named context.

So when code owning that chain of network calls would need to cancel (in 
effect kill) the chain, it would just call a lib function called Cancel(ctx 
string) and the whole chain of calls would be killed: every network 
functions must obey a Cancel() call.

As far as extending it to Reader, it does not make sense to me. The reason 
why there is a Context today is that failures in chained network calls are 
difficult to detect and correct, because of inherent network 
characteristics. That is not a general case for a Reader.

On Monday, August 7, 2017 at 3:40:05 PM UTC+2, Michal Strba wrote:
> Hi everyone!
> I've written a blog post called 'Context should go away for Go 2':
> https://faiface.github.io/post/context-should-go-away-go2/
> The post is about the cancelation problem in Go, how context package 
> solves it, why context package is bad anyway, and that Go 2 should do 
> something about it. Hope you enjoy reading ;)
> PS: I'm not sure if this post is acceptable for an experience report. If 
> you think it is / isn't, let me know.
> Michal Štrba

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.

Reply via email to