What does time.AfterFunc do, and on which goroutine does its function run?

## The API ```go func AfterFunc(d Duration, f func()) *Timer ``` It schedules `f` to be called once, after `d` has elapsed. Unlike `time.After` and `time.NewTimer`, nothing is delivered on a channel: the runtime calls the function for you. The returned `*time.Timer` is a control handle only — the documentation is explicit that this timer's `C` field is not used and is nil, so a receive on it would block forever. ## Which goroutine runs the function When the timer expires, the runtime starts a **new goroutine** and calls `f` on it. It does not run on the goroutine that called `AfterFunc`, and it does not run on some internal runtime thread you must be gentle with. Three practical consequences: 1. **`f` runs concurrently with everything else.** Any state it reads or writes needs a mutex, an atomic, or a channel, exactly as for any other goroutine. This is a common source of races because the call site looks like a scheduling detail rather than a goroutine spawn. 2. **A panic in `f` is not contained.** An unrecovered panic on any goroutine terminates the whole program, and no other goroutine can recover it. If `f` does anything that might panic, it must `defer` its own `recover`. 3. **The function should be short.** A long-running `f` is just a long-running goroutine with a delayed start; if that is what you want, be explicit about it. ## Stop, and what it does not promise `Stop` returns `true` if it cancelled the timer before it fired and `false` if the timer had already fired or had already been stopped. When it returns `false`, `f` may be about to run, may be running right now, or may have finished — `Stop` does not wait for `f` to complete before returning. That is the trap: ```go t := time.AfterFunc(5*time.Second, func() { // runs on a new goroutine }) if !t.Stop() { // already fired: f may still be running } ``` If your cleanup path assumes that after `Stop` nothing else will touch a resource, that assumption is wrong. To get the guarantee you have to build it: have `f` close a channel or call `WaitGroup.Done` as its last act, and wait on that. `Reset(d)` re-arms the same timer to call `f` again after a new duration, which is how you push a deadline back without allocating a fresh timer. ## Why not just a goroutine and a sleep? `go func() { time.Sleep(d); f() }()` looks equivalent, and for one call it effectively is. The differences show up at scale and at cancellation time: - **Cost.** `AfterFunc` registers one runtime timer and only creates a goroutine when it fires. The sleep version creates the goroutine immediately, each with its own stack, and parks it for the whole duration. A large number of pending delayed actions is far cheaper as timers than as sleeping goroutines. - **Cancellation.** A sleeping goroutine cannot be woken early without extra plumbing; an `AfterFunc` timer has `Stop` and `Reset` built in. - **Rescheduling.** Pushing the deadline out is one `Reset` call rather than tearing down and recreating a goroutine. ## Where it fits `AfterFunc` suits fire-and-forget deadline actions: mark a pending item abandoned, flush a batch that has been idle too long, close a resource that was never claimed. It fits badly when the deadline needs to compete with other events — if you want "either a reading arrives or the deadline passes", you want a timer channel in a `select`, not a callback that has to synchronise its way back to the waiting goroutine. The failure mode to watch for in a long-lived agent is arming an `AfterFunc` per unit of work and never stopping the ones whose work finished early. Each pending callback is a scheduled action the runtime must still honour, and if your code also stores the returned `*time.Timer` in a map to be able to cancel it, that map is a retention point that grows with uptime unless entries are removed as well as stopped.