3 ms·
> What annoys me about Context is there's no way to tell if it's honored by the callee. On the occasions where I've needed that I've used a WaitGroup and done
by bborud 3y ago
> What annoys me about Context is there's no way to tell if it's honored by the callee.
On the occasions where I've needed that I've used a WaitGroup and done wg.Add(1) at the point where I start goroutines and then have a defer wg.Done() as the first thing in the goroutine. I don't think the functionality belongs in Context. And if you put it there, you'd just end up complicating things.
> And when I'm accepting Context I'm annoyed at having to write handlers for it all through the stack having no idea how/if people will use it.
How would you propose you do it instead?
- tsimionescu 3y ago> On the occasions where I've needed that I've used a WaitGroup and done wg.Add(1) at the point where I start goroutines and then have a defer wg.Done() as the first thing in the goroutine. I don't think the functionality belongs in Context. And if you put it there, you'd just end up complicating things. I'm not sure this is the same thing. The point of Context is to propagate cancelations or timeouts across multiple layers of your app and libraries, it's not supposed to be useful for directly started goroutines.
- bborud 3y agoPerhaps not, but if you have no idea what ought to be cancelled how would it help you to know that something has been cancelled? What changes would you make to Context?