On Wed, Nov 2, 2016 at 9:11 PM, Ian Davis <m...@iandavis.com> wrote:
> On Wed, Nov 2, 2016, at 10:35 PM, Gustavo Niemeyer wrote:
>
> Hello there,
>
> On Wed, Nov 2, 2016 at 11:09 AM, Ian Davis <m...@iandavis.com> wrote:
>
>
>
> On Wed, Nov 2, 2016, at 12:56 PM, 'Axel Wagner' via golang-nuts wrote:
>
> AIUI: A child or grandchild function is not supposed to signal that. They
> can return an error and let the parent cancel, or they can create their own
> child context WithCancel and cancel that. Context doesn't replace
> exceptions.
>
>
>
> OK I see that. I think I don't understand the purpose of the Err method if
> the function that creates the context is the one that cancels it or closes
> the Done channel. It seems that the only purpose would be to detect a
> Timeout.
>
>
> Err allows you to do this:
>
> select {
> case <-ctx.Done():
> return ctx.Err()
> ...
> }
>
>
> In this situation, other than a timeout, what would be closing the Done
> channel? The goroutine that created the context already knows the error
> since it's the only one that is supposed to call cancel.
>
The goroutine that created the context closes the channel. The error
returned informs the call site why the task was interrupted, and that call
site will often not be the calling goroutine. Without it you'd have to
return fmt.Errorf("interrupted") or something, which is both more boring
and less precise than simply calling ctx.Err().
> You should consider context a way to implement dynamic scoping
> <https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynamic_scoping>.
> A context is a thing valid for the current stack frame and downwards and
> should never affect the stack upwards. Which is also why there's the "put
> values in there, not pointers" rule; if you have a pointer, it might modify
> an upstack context.
>
> The advantage of that (and context in general) is, that you don't need to
> worry too much about synchronization and everything; as a context is
> fundamentally immutable (-ish), it's fine to pass it to separate
> goroutines, because they can only do stuff with it downstack.
>
>
> Yes, this is what I am trying to do. I was wondering whether the returned
> cancelFunc is something that could be passed downstream to signal parents
> that work should be aborted.
>
>
> No, the purpose of Context is the opposite: fired tasks are free to do
> whatever they please until it's time to stop, because the boss says so.
> Once that happens, error propagation happens as usual to tell what went
> wrong.
>
> The http://gopkg.in/tomb.v2 package works closer to the model you
> describe.
>
>
> Thanks. I've used tomb before and I've played with the context/tomb
> integration. I guess I need both.
>
Yeah, tomb and context have some overlap, but they cover different needs.
Pretty much every use I made of tomb was on an internal implementation
detail to organize the required concurrency inside a service, while context
is very nice across API boundaries.
gustavo @ http://niemeyer.net
--
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.
