5 ms·
> canceling the context should always be safe, and is more likely to safely handle what otherwise would be a bug, than it is to cause a bug. They gave an examp
by scottlamb 5y ago
> canceling the context should always be safe, and is more likely to safely handle what otherwise would be a bug, than it is to cause a bug.
They gave an example of a bug it caused, and I haven't seen any examples of bugs it would have prevented, so I'm not sure I agree.
- reltuk 5y agoI think the contract in the context package is that WithCancel may leak resources if cancel is not called and the parent context is cancelable but never canceled. At least, that seems to be the behavior I see in the implementation here: https://github.com/golang/go/blob/master/src/context/context.go#L232 https://github.com/golang/go/blob/master/src/context/context... So in this case, errgroup probably doesn't have a choice and needs to call cancel() at some point.
- scottlamb 5y agoAhh. Yeah, that's unfortunate but explains this choice. btw, I realized I'm not being entirely fair in saying it caused a bug. There would have been one anyway. If conflictsBuilder.Wait() failed, it wouldn't cancel the other two operations. It'd wait them out even though the overall operation was doomed. Maybe not a very noticeable bug under normal conditions but still not right.