Keep control of goroutines with a Context construct

Programming Snapshot – Go Context

© Lead Image © alphaspirit, 123RF.com

© Lead Image © alphaspirit, 123RF.com

Article from Issue 246/2021
Author(s):

When functions generate legions of goroutines to do subtasks, the main program needs to keep track and retain control of ongoing activity. To do this, Mike Schilli recommends using a Context construct.

Go's goroutines are so cheap that programmers like to fire them off by the dozen. But who cleans up the mess at the end of the day? Basically, Go channels lend themselves to communication. A main program may need to keep control of many goroutines running simultaneously, but a message in a channel only ever reaches one recipient. Consequently, the communication partners in this scenario rely on a special case.

If one or more recipients in Go try to read from a channel but block because there is nothing there, then the sender can notify all recipients in one fell swoop by closing the channel. This wakes up all the receivers, and their blocking read functions return with an error value.

This is precisely the procedure commonly used by the main program to stop subroutines that are still running. The main program opens a channel and passes it to each subroutine that it calls; the subroutines in turn attach blocking read functions to it. When the main program closes the channel later on, the blocks are resolved, and the subroutines proceed to do their agreed upon cleanup tasks – usually releasing all resources and exiting.

Ripcord on Three

As an intuitive example, Listing 1 shows a main program that calls the function work() three times in quick succession. The function returns almost immediately, but each time it sets off a goroutine internally that counts to 10 in one second steps and prints the current counter value on standard output each time. Each of these goroutines would now continue to run for their entire scheduled 10 seconds, even after the function calling them had long terminated, if it weren't for the main program call to close(), pulling the ripcord after three seconds in line 15.

Listing 1

grtest.go

01 package main
02
03 import (
04   "fmt"
05   "time"
06 )
07
08 func main() {
09   done := make(chan interface{})
10   work(done)
11   work(done)
12   work(done)
13
14   time.Sleep(3 * time.Second)
15   close(done)
16   time.Sleep(3 * time.Second)
17 }
18
19 func work(done chan interface{}) {
20   go func() {
21     for i := 0; i < 10; i++ {
22       fmt.Printf("%d\n", i)
23
24       select {
25       case <-done:
26         fmt.Printf("Ok. I quit.\n")
27         return
28       case <-time.After(time.Second):
29       }
30     }
31   }()
32 }

The done channel, used as a mechanism for this synchronization, is created in line 9. interface{} specifies the data type transported in the channel as generic, since the program does not send any data to the channel or read from it later on, but will only detect a future close command.

How exactly do the workers get to hear the factory siren at this point? After all, they are still busy doing their job and compiling results or just busily passing time, as in this example.

This "busy waiting" is implemented by the select construct starting in line 24. Using two different case statements, select waits simultaneously for one of two possible events: the channel reader <-done attempts to obtain data from the done channel or it picks up an error if main closes the channel. Or else the timer started by time.After() in line 28 expires after one second and directs the select construct to jump to the corresponding empty case, which does nothing except continue the surrounding endless for loop.

During the first three seconds of running the sample program, it will show timer ticks from all three subroutines. But shortly after, things start happening, because the main program closes the done channel, which triggers an error in the first case in line 25; this in turn causes the worker to display the Ok. I quit. message and exit its goroutine with return. Figure 1 shows the running program's output.

Figure 1: In the test program shown in Listing 1, the siren goes off for all three workers after three seconds.

And Now for Real

Instead of counting to 10 and always waiting a second between each step, a work() function in the real world would, for example, perform time-consuming tasks such as retrieving a web page over the network or using a tailf-style technique to detect growth in one or more locally monitored files. However, even in these situations, a server program may have to pull the emergency brake – whether because the requesting user has lost patience or data processing on the back end is simply taking too long for the main program and it wants to move on to serve other requests.

At the end of a standalone main program such as the one in Listing 1, the operating system does indeed clean up any goroutines that are still running and automatically releases the allocated resources such as memory or file handles. However, a server program must not rely on this luxury, because canceling a request – for whatever reason – does not terminate the program. It may have to continue running for weeks, without orphaned functions utilizing more and more memory, until the dreaded out-of-memory killer steps in and takes everything down.

Limits

By the way, functions that send data to each other via channels must be aware of two borderline cases. If they send a message to a channel that has already been closed, the Go program goes into panic mode and aborts with an error. On the other hand, if a function reads from a channel where nobody can send anything anymore because all writers have given up the ghost, the program flow will hang forever. In the case at hand, however, that's the intended behavior: No data will ever flow through the channel used, because the program only takes advantage of the fact that reading from a closed channel generates an error.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Simultaneous Runners

    In the Go language, program parts that run simultaneously synchronize and communicate natively via channels. Mike Schilli whips up a parallel web fetcher to demonstrate the concept.

  • Rat Rac

    If program parts running in parallel keep interfering with each other, you may have a race condition. Mike Schilli shows how to instruct the Go compiler to detect these conditions and how to avoid them in the first place.

  • Let's Go!

    Released back in 2012, Go flew under the radar for a long time until showcase projects such as Docker pushed its popularity. Today, Go has become the language of choice of many system programmers.

  • Progress by Installments

    Desktop applications, websites, and even command-line tools routinely display progress bars to keep impatient users patient during time-consuming actions. Mike Schilli shows several programming approaches for handwritten tools.

  • Motion Sensor

    Inotify lets applications subscribe to change notifications in the filesystem. Mike Schilli uses the cross-platform fsnotify library to instruct a Go program to detect what's happening.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News