Closed
Description
go version devel go1.21-3ed8a1e629 Tue Mar 28 05:41:44 2023 +0000 linux/amd64
I raised this point in #57928.
I'm not entirely sure whether the semantics of the stop
return from context.AfterFunc
are correct. The argument for it being this way is by reference to Timer.Stop
but I'm not convinced that Timer.Stop
is good precedent, because that API is notoriously error-prone and hard to use.
An alternative semantic could be:
// The stop function reports whether the function has been successfully stopped; that is, it returns false
// if and only if the function has been invoked already.
That makes it feasible to call stop
multiple times concurrently and have consistent results between them, and it seems to me like a simpler invariant to explain.
I'm wondering what the use case is for knowing whether this is the stop
call that prevented the function running.