Hi all, I want to confirm whether my understanding related to handling
HTTP client disconnections is correct or not.

Consider this:

func longRunningProcessing(ctx context.Context, w http.ResponseWriter) {
    done := make(chan bool)
    go func() {
        expensiveWork() # This is a blocking expensive processing call
        done <- true
   }()
    select {
    case <-ctx.Done():
      log.Printf("Client disconnected. Cancelling expensive operation.")
      return
     case <- done:
      fmt.Fprintf(w, "Done!")
    }
}

func apiHandler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    longRunningProcessing(ctx)
}

When a client connection close is detected, the Done() call in select
unblocks and the call goes out of the longRunningProcessing()
function.
However, the goroutine with the expensiveWork() is actually still running?

It seems like there is *no* way there is *not* going to be a goroutine
leak (and resources associated with it) in a pattern like the above
unless
I have control over expensiveWork() and can instrument it with a child
context. I am also thinking if there is a way to obtain the behavior
similar to exec.CommandContext() command
which does a hard kill of the external process when the context is cancelled.

Thanks for any insights and clarifications.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANODV3k9gF0gLWB1Z1OGaH-ArPbq8mNPKx9mzrTOTCa-kZZmvg%40mail.gmail.com.

Reply via email to