If you treat a timeout as a kind of failure, then context makes more sense.
In fact, context deals with unblocking a procedure when this is found
necessary. That's really all there is to it. Why it is blocked, when it
needs to be unblocked, just confuse the picture. The context narrows the
"damage" required to unblock something to functions that have been
instructed how to deal with it.
In the full picture, the "error" argument to a function necessarily becomes
part of the context, not of the argument list (return values are just a
special case of arguments, just like the receiver is). So is a timeout, of
course, and distinguishing them is an option in some cases, a necessity in
others, but from a "context" perspective it is what the Univac Exec-8
programmers rightly called a "contingency".
The name "context" could not have been more fortunate, as the context is
very much the gift-wrap that keeps related activities linked and determines
what happens when the defined conditions (and perhaps some unexpected ones)
are encountered.
That, at least, is my uneducated understanding of where the "context"
concept is heading. I'm looking forward to a much more robust programming
paradigm when the final outcome is eventually reached.
Lucio.
On Tuesday, 8 August 2017 18:20:08 UTC+2, Piero de Salvia wrote:
>
> 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 chain.
>
> 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.
