>
> I find it awkward
> and risky if I cannot pass down a cancelable context down the stack
> where things may not return.
Absolutely, we always want to be able to pass that down regardless.
Those that are
> lower the stack are not enforcing timeouts or cancellations, they are
> merely getting a
On Wed, Sep 20, 2023 at 5:04 PM Jerry Londergaard
wrote:
>
> Are you comfortable though, *relying* on this behaviour down the stack to
> enforce the timeout that was declared
> further up the stack (leaving potentially leaked goroutines out of it...)?
That's the nature of handling requests
>
> If the new goroutine can periodically
> check context cancellation and needs to do some cleanup, then it is
> best to pass the context down, clean up, and return on cancellation.
Understood. I would always pass the context down anyway,
letting that callee decide whether or not it wants to
On Wed, Sep 20, 2023 at 7:47 AM Jerry Londergaard
wrote:
>
> When using a context.WithTimeout, I always felt that it should be the
> function where the context was created should be the one that ensures that it
> (the current function) does not block longer than intended. That is to say,
> it
When using a context.WithTimeout, I always felt that it should be the
function where the context was created should be the one that ensures that
it (the current function) does not block longer than intended. That is to
say, it should call context.WithTimeout(), and then run the subsequent code
