Keep control of goroutines with a Context construct
Delays Are Punished
To prevent the chkurl()
worker from dilly-dallying, line 16 sets a context with a timeout, which it passes as the ctx
variable to the worker bee. It uses the default net/http
package in an inner goroutine (starting in line 44) running inside an outer goroutine to retrieve the web page, and pushes the status code returned by the web server into the local httpch
channel when it's available.
This means that the inner goroutine is stuck until someone at the other end of the httpch
channel starts reading. This will happen in the subsequent select
construct starting in line 53, which kicks in on one of two events: either when a web request response comes from the httpch
channel, or when the main program loses patience and ctx.Done()
returns with an error. In the latter case, the function outputs a Timeout!! message and sets the HTTP return code to 501. If, on the other hand, everything works just fine, line 55-56 pushes the returned code and the associated URL into the results
channel.
Figure 2 shows the flow of the compiled binary. The first three requests come back relatively quickly. The fourth one would keep dawdling for a massive five seconds, but the context timeout of two seconds as defined in line 16 sends an early termination signal, and the worker bee's status code comes back as a 501, as specified in line 60.
![](/var/linux_magazin/storage/images/issues/2021/246/fighting-chaos/figure-2/784624-1-eng-US/Figure-2_large.png)
The combination of two nested goroutines in chkurl()
is necessary, by the way, because sending data into a channel and extracting the data at the other end needs to be synchronized. Letting the program simply send to the channel first and then read from it will not work, as the sender will hang forever if no receiver is listening. To ensure that the whole enchilada in Listing 3 runs smoothly, the sender sends its values to the channel in an asynchronous goroutine. The receiver can dock afterwards at their leisure; as soon as they do so, the sender unblocks and data gets sent through the channel.
Precision, No Sleep
You might have noticed that Listing 3 does not rely on unreliable Sleep
commands for synchronization when collecting worker data, as done sloppily in Listings 1 and 2. Sleeping for a set time is no guarantee that things have finished, as data sent over the network can arrive unusually slowly. Anything is possible on the Internet; worst case, the program might exit before the last goroutine had a chance to send its results up the channel.
Listing 3 therefore uses two for
loops in lines 28 and 32, each of which counts to four: once to call chkurl()
four times and later to collect the results from the return channel four times. The order of requests and responses can get mixed up this way, but the program structure guarantees that all the results are complete and nothing gets accidentally dropped.
Goroutines are a great way to deploy code with components that can run concurrently. Note, however, that the concurrent code will only run in parallel if the platform supports it (e.g., thanks to multithreading and/or a multi-core processor). The difference between concurrency and parallelism is therefore quite relevant, as Go guru Rob Pike impressively explains in a video [2] that is definitely worth watching.
Infos
- Go Context: https://blog.golang.org/context
- "Concurrency is not parallelism": https://blog.golang.org/waza-talk
« Previous 1 2 3
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
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](https://www.linux-magazine.com/var/linux_magazin/storage/images/media/linux-magazine-eng-us/images/misc/learn-more/834592-1-eng-US/Learn-More_medium.png)
News
-
NVIDIA Released Driver for Upcoming NVIDIA 560 GPU for Linux
Not only has NVIDIA released the driver for its upcoming CPU series, it's the first release that defaults to using open-source GPU kernel modules.
-
OpenMandriva Lx 24.07 Released
If you’re into rolling release Linux distributions, OpenMandriva ROME has a new snapshot with a new kernel.
-
Kernel 6.10 Available for General Usage
Linus Torvalds has released the 6.10 kernel and it includes significant performance increases for Intel Core hybrid systems and more.
-
TUXEDO Computers Releases InfinityBook Pro 14 Gen9 Laptop
Sporting either AMD or Intel CPUs, the TUXEDO InfinityBook Pro 14 is an extremely compact, lightweight, sturdy powerhouse.
-
Google Extends Support for Linux Kernels Used for Android
Because the LTS Linux kernel releases are so important to Android, Google has decided to extend the support period beyond that offered by the kernel development team.
-
Linux Mint 22 Stable Delayed
If you're anxious about getting your hands on the stable release of Linux Mint 22, it looks as if you're going to have to wait a bit longer.
-
Nitrux 3.5.1 Available for Install
The latest version of the immutable, systemd-free distribution includes an updated kernel and NVIDIA driver.
-
Debian 12.6 Released with Plenty of Bug Fixes and Updates
The sixth update to Debian "Bookworm" is all about security mitigations and making adjustments for some "serious problems."
-
Canonical Offers 12-Year LTS for Open Source Docker Images
Canonical is expanding its LTS offering to reach beyond the DEB packages with a new distro-less Docker image.
-
Plasma Desktop 6.1 Released with Several Enhancements
If you're a fan of Plasma Desktop, you should be excited about this new point release.