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.
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. On Wed, Nov 2, 2016 at 1:30 PM, Ian Davis <m...@iandavis.com> wrote: > On Wed, Nov 2, 2016, at 12:12 PM, Axel Wagner wrote: > > From https://godoc.org/context > > Failing to call the CancelFunc leaks the child and its children until the > parent is canceled or the timer fires. The go vet tool checks that > CancelFuncs are used on all control-flow paths. > > > I'm not sure how it's *meant* to be used, but a way to do it, while > adhering to everything you say, is to use > defer cancel() > > In that case, a) cancel will always be called at least once, b) if you > want to cancel it before, you can. Just call cancel and c) if you call > ctx.Err() (e.g. in a return statement) it will return Cancelled iff you > called cancel before in the same function. > > So, yes. If you get a cancel function, always make sure to call it (you > might use go vet for that) at least once and a simple way to ensure that > would be defer. > > > After sending the message I noticed that govet checks that cancel is > called, so that does answer the main part of my question. > > I think I am not quite grasping the idomatic use of contexts and cancel. I > understand that the function that creates the context via WithCancel should > call the canceFunc and defer seems the obvious way to do that. > > But I'm not understanding the idiomatic way for child and grandchild > functions to signal that the overall operation cannot be completed or has > partially failed. Should they be calling the cancelFunc or closing the > Done() channel or something else? > > -- 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.
