One of the traps of concurrency is "incomplete work" which occurs when a program terminates before outstanding Goroutines complete. Depending on the program, this may be a serious problem. This post demonstrates the trap and discusses possible solutions.
Goroutine Leaks are a common cause of memory leaks in Go programs. In my previous post, I presented an introduction to Goroutine leaks and provided one example of a common mistake that many Go developers make. Continuing that work, this post presents another scenario on how Goroutines could be leaked.
Goroutine leaks are a common source of memory leaks in concurrent programs. This post defines Goroutine leaks and provides one example of a leak that is easy to miss in production code.
My full time engagement is with the very talented team at Ardan Labs.
We specialize in the Go programming language and offer training and consulting
From February 2015 to February 2016 I was a contracting engineer at Wrecking
Ball Media Group. As a part of this team I worked on a web based
community platform for Adobe. The project utilized several different
APIs from Adobe and other vendors to create a white labeled site for connecting
and empowering creative youth.
This is a talk I presented at the first Kansas Linux Fest in March 2015.
I gave it again that month at my company’s internal roundtable and again for
devICT that July.
In Go web development the Gorilla web toolkit is a very popular
collection of libraries for common web tasks. The
provides an easy interface for using/storing users’ session data. There was no
implementation for Cassandra DB so I created one.
BDD in Go is made easier using the Ginkgo and Gomega
packages. Gomega specifically provides a collection of matchers for asserting
that results match expectations. When using these tools to test an API I was
developing I noticed some common patterns appearing around the assertion of
HTTP status codes. I created the
github.com/jcbwlkr/httpmatchers package to
simplify some of those patterns.