Can I force termination a goroutine without waiting for it to return?

Question

Let me use an example:

func WaitForStringOrTimeout() (string, error) {
  my_channel := make(chan string)
  go WaitForString(my_channel)

  select {
  case found_string := <-my_channel:
    return found_string, nil
  case  <-time.After(15 * time.Minute):
    return nil, errors.New("Timed out waiting for string")
  }
}

In this simple example, I have some function WaitForString which blocks for awhile and eventually may return a string. I want to wrap WaitForString with this code which either returns the same string or times out with an error.

If a string is found quickly, is there still a goroutine running with a 15 minute sleep statement somewhere or is this garbage collected somehow?

If the timeout occurs and a string is never found, is there still a goroutine running WaitForString, even though there are no other routines that could observe it's output? What if WaitForString allocates a lot of memory but never returns?

Is there some way I can make WaitForString() become aware of the timeout occurring and give up?

Answer 1

In general, no there isn't a way to stop another goroutine. There is a runtime.Goexit function that can be used to cause the current goroutine to exit (even if called from a deep call frame), but nothing to cause other goroutines to exit.

For the specific case of the time module, there isn't a separate goroutine handling each timer or ticker: instead, timers are centrally managed by the runtime so it can tell when it next needs to wake up.

While there's no goroutine hanging around, the channel and a small bookkeeping struct will stick around for the 15 minutes.

If this is a problem, consider using time.NewTimer instead of time.After, and manually stop the timer when you return. For example:

t := time.NewTimer(15 * time.Minute)
defer t.Stop()
select {
case found_string := <-my_channel:
    return found_string, nil
case  <-t.C:
    return nil, errors.New("Timed out waiting for string")
}

time.After is really useful for exact periodic behaviour, whereas time.NewTimer works fine for simple timeouts.