Keep control of goroutines with a Context construct
Programming Snapshot – Go Context

© Lead Image © alphaspirit, 123RF.com
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.

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
(incl. VAT)
Buy Linux Magazine
Direct Download
Read full article as PDF:
Price $2.95
News
-
GNOME 43 To Bring Some Exciting New Features
GNOME 43 is getting close to the first alpha development release and it promises to add one particular feature that should be exciting to several users.
-
KaOS 2022.06 Now Available With KDE Plasma 5.25
The newest iteration of KaOS Linux not only adds the latest KDE Plasma desktop but sets LibreOffice as the default.
-
Manjaro 21.3.0 Is Now Available
Manjaro “Ruah” has been released and includes the latest Calamares installer, GNOME 42, and much more.
-
SpiralLinux is a New Linux Distribution Focused on Simplicity
A new Linux distribution, from the creator of GeckoLinux, is a Debian-based operating system with a focus on simplicity and ease of use.
-
HP Dev One Linux Laptop is Now Available for Pre-Order
The System76/HP collaboration Dev One laptop, geared toward developers, is now available for pre-order.
-
NixOS 22.5 Is Now Available
The latest release of NixOS with a much-improved package manager and a user-friendly graphical installer.
-
System76 Teams up with HP to Create the Dev One Laptop
HP and System76 have come together to develop a new laptop, powered by Pop!_OS and aimed toward developers.
-
Titan Linux is a New KDE Linux Based on Debian Stable
Titan Linux is a new Debian-based Linux distribution that features the KDE Plasma desktop with a focus on usability and performance.
-
Danielle Foré Has an Update for elementary OS 7
Now that Ubuntu 22.04 has been released, the team behind elementary OS is preparing for the upcoming 7.0 release.
-
Linux New Media Launches Open Source JobHub
New job website focuses on connecting technical and non-technical professionals with organizations in open source.