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.
