On Thu, Feb 14, 2019 at 2:13 AM Jingguo Yao <yaojing...@gmail.com> wrote: > > https://blog.golang.org/context uses the following code to cancel the request > if ctx.Done is closed before the goroutine exits: > > func httpDo(ctx context.Context, req *http.Request, f func(*http.Response, > error) error) error { > // Run the HTTP request in a goroutine and pass the response to f. > c := make(chan error, 1) > req = req.WithContext(ctx) > go func() { c <- f(http.DefaultClient.Do(req)) }() > select { > case <-ctx.Done(): > <-c // Wait for f to return. > return ctx.Err() > case err := <-c: > return err > } > } > > I have two questions about this piece of code. > > First, if neither "http.DefaultClient.Do" nor "f" does a check of > "ctx.Done()", "f(http.DefaultClient.Do(req))" can't be cancelled. It means > that if I want to use "ctx.Done()" to cancel some functions, I need to check > "ctx.Done()" at various points in the functions which I want to cancel. Is my > understanding correct?
Yes. > Second, if I don't want to do a cleanup of "http.DefaultClient.Do" and "f", I > can just remove "<-c // Wait for f to return.". If I do this, there will be a > dangling running goroutine after httpDo returns. Is this approached > considered bad? While there are specific cases where leaving a dangling goroutine is harmless, as a general guideline it should be avoided. It's easy to imagine a busy server quickly building up many thousands of dangling goroutines, and they do have a cost. Ian -- 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.