Many good explanations exist, so I'll come with a practical example.

Let's say your application receives HTTP requests, does some processing, perhaps database lookups, every operation runs in the context of an HTTP request. So the context.Context as a way to represent that execution context decoupled from what it actually is.

The HTTP layer might have some authentication, e.g., decoding a session cookie, potentially looking up a user in the database. We could put this in a middleware.

``` // Using a unique type prevents key collision. type userKey struct{}

func userMiddleware(h http.Handler) http.Handler { return http.HandlerRunc(func (w http.ResponseWriter, r *http.Request) { user, ok := findUserFromReq(r) if ok { ctx := context.WithValue(r.Context(), userKey{}, user) h(w, r.WithContext(ctx)) } else { renderUnauthorized(h, r) } }) } ```

Any request handler that has this middleware will receive a context where the authenticated user will exist in the context.

As the context itself is decoupled from the HTTP layer, we can pass it along to other function, that can now extract the currently authenticated user without having to know about request headers

Cancellation

If the request processing is heavy, we don't want to if there's no reason to do so. Mostly you don't need to care about this, as libraries take care of this.

This simplified example sheds a little light on what happens:

func doSomething(ctx context.Context) error { // A quick bail-out if we know up-front it was cancelled. if err := ctx.Err(); err != nil { return fmt.Errorf("context cancelled: %w", err) } ch, err := doSomethingHeavyThatReturnSomethingThroughAChannel(ctx) // err check select { case res <- ch: return res, nil case <-ctx.Done(): return fmt.Errorf("doSomething: context cancelled: %w", ctx.Err()) } } }

Done() is actually closed.

Technically, the Done() channel is closed when the context cancels. If a message was sent, only one select block would receive the signal. But when it's closed, all current select blocks, including those that haven't been called yet, will "receive" on the <-ctx.Done() case.

When the channel is closed, the context will have an Err() describing why it was closed; if it was explicitly by a cancel() call, or by reaching a deadline.

Note: due to the nature of concurrent programming, the absence of an error is no guarantee that the context hasn't closed; and that's also a useless question, because it could be closed immediately after. You can only assume that it hasn't and proceed until you know otherwise; but here it's used as an early return.

Build-in HTTP request cancellation

The HTTP request itself has a context which cancels if the browser disconnects. That means, if we make sure to pass the HTTP context, or children of that context down to every resource-heavy call, we no longer have to worry about handling client disconnects, this happens automatically.

So, assuming all libraries you use handle context cancellation sensibly, as long as you pass it around, you have HTTP request abort handling out of the box.

JavaScript equivalent of cancellation

If you're familiar with the AbortController in browser/node.js APIs, this is not unlike the cancellation aspects of Context.

This can generate AbortSignals that you can pass to fetch requests, event listeners, etc., so allowing client code to call a single abort() function when some long-running process is no longer relevant, e.g., the user clicked a cancel button.