Skip to content

proposal: context: reconsider semantics for AfterFunc stop function #60156

Closed
@rogpeppe

Description

@rogpeppe
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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions