Concurrency in Go

Appendix A. Appendix

As you set forth on your journey of writing concurrent code, you’ll need the tools to write your program and analyze it for correctness, and a few helpful pointers to help you understand what’s happening within your programs. Lucky for you, the Go ecosystem has a rich set of tooling both from the Go team and from the community! This appendix will discuss some of these tools and how they can aid you before, during, and after development. Since this book is focused on concurrency, I’m going to constrain the conversation to only topics that help you write or analyze concurrent code. We’ll also briefly look at what happens when goroutines panic. It doesn’t happen often, but the output can be a bit confusing the first time you see it.

Anatomy of a Goroutine Error

It happens to the best of us: sooner or later, your program will panic. If you’re lucky, no humans or computers will be harmed in the process, and the worst that will happen is you’ll be staring down the bad end of a stack trace.

Prior to Go 1.6, when a goroutine panicked, the runtime would print stack traces of all the currently executing goroutines. Sometimes this made it difficult (or at least time-consuming) to determine what had happened. At the time of this writing, Go 1.6 and greater greatly simplify things by printing only the stack trace of the panicking goroutine.

For example, when this simple program is executed:

1 package main
2 
3 func main() {
4     waitForever := make(chan interface{})
5  ...