Use of context interrupts in the Go language

More and more people are developing applications using Go, most of which use context operations, such as making HTTP calls, fetching data from a database, or performing asynchronous operations with Go-Routines. The most common use is to pass common data that can be used by all downstream operations.

Why do we need to interrupt operations?

Normally we should make a request via HTTP, then query the database and return the data via HTTP request

If everything were perfect, the sequence diagram would look something like this:

But what happens if the user cancels the request in the middle? This can happen, for example, if the client requests to close the browser in the middle. If not cancelled, the application server and database will continue working and resources will be wasted:

Ideally, if we know that the process (in this case, the HTTP request) is stopped, we want all downstream components of the process to be stopped:

Context interrupts in Go:

Now that we know why interrupts are needed, let’s look at how to implement them in Go.

We typically need to implement interrupts in one of two ways:

1. Listen to interrupt
2. A break

So let’s look at the Context first

1. // context
2. type Context interface {
3. Done() <-chan struct{}
4. Err() error
5. Deadline() (deadline time.Time, ok bool )
6. Value(key interface{}) interface {}
7. }

The context, the context interface

• Methods in the context package are thread-safe and can be used by multiple threads
• Done returns a closed channel when Context is canceled or timeout
• After the Done channel is closed, Err represents the reason for the closure
• If so, Deadline returns the time when the Context will close
• Value returns the Value associated with the key if it exists, nil if it does not

Listening interrupt:

Let’s implement a two-second timeout HTTP service. If the request is cancelled before then, we return the result immediately:

1. func main() {
2. // Create an HTTP server that listens on port 8000
3. http.ListenAndServe(“:8000”, http.HandlerFunc( func(w http.ResponseWriter, r *http.Request) {
4. ctx := r.Context()
5. // This prints to STDOUT to show that processing has started
6. fmt.Fprint(os.Stdout, “processing request\n”)
7. // We use `select` to execute a peice of code depending on which
8. // channel receives a message first
9. select {
10. case <-time.After(2 * time.Second):
11. // If we receive a message after 2 seconds
12. // that means the request has been processed
13. // We then write this as the response
14. w.Write([]byte( “request processed”))
15. case <-ctx.Done():
16. // If the request gets cancelled, log it
17. // to STDERR
18. fmt.Fprint(os.Stderr, “request cancelled\n”)
19. }
20. }))
21. }

Time-based interrupts

In many cases, our services have to meet SLA requirements. We may need to interrupt based on timeout! Of course we can also use in RPC requests and DB operations!

1. // The context will be cancelled after 3 seconds
2. // If it needs to be cancelled earlier, the `cancel` function can
3. // be used, like before
4. ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
6. // The context will be cancelled on 2009-11-10 23:00:00
7. ctx, cancel := context.WithDeadline(ctx, time.Date(2009 , time.November, 10, 23, 0, 0 , 0, time.UTC))

Conclusion:

All context’s parent object, the root object, is an empty context, it can’t be canceled, it has no value, it never gets canceled, it doesn’t have a timeout, it always exists as the top-level context for processing requests, Then create child objects with WithCancel and WithTimeout functions to obtain cancel and timeout capabilities

When the top-level request function ends, we can cancel a context to signal that the other routine ends

The WithValue method can add a key-value pair to the context that a different routine gets

To play to admire