5 ms·

What annoys me about Context is there's no way to tell if it's honored by the callee. And when I'm accepting Context I'm annoyed at having to write handlers fo

What annoys me about Context is there's no way to tell if it's honored by the callee. 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.

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 ago
    Perhaps 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?
rad_gruchalski 3y ago
> What annoys me about Context is there's no way to tell if it's honored by the callee. Everybody has to be decent enough to do their part. > 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. Thank you for doing yours :)

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 ago
  Perhaps 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?

rad_gruchalski 3y ago

> What annoys me about Context is there's no way to tell if it's honored by the callee. Everybody has to be decent enough to do their part. > 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. Thank you for doing yours :)