Sending Context across channel - is it an anti-pattern?

[Sharad Jain]

Hello,

All the material about Golang Context on web confirm that passing Context to goroutines is a-ok and encouraged. I didn't find much information on whether passing Context across channel is ok or not.

In our use-case, we have a worker pool which is setup to allow a finite number of goroutines to process the work. The work items are fed using a go-channel. We can think of each work-item as a separate request (kafka event in our case). We create a new Context for each of these incoming event and send them across channel to the worker pool. The question is whether including Context as part of this work-item is an ok thing to do or not. It seems to be working fine, though we are curious if there is any downside, and if so what would be a better design.

Thanks for your time,

[Brian Candler]

A (cancellable) context is mostly just a channel, which is closed as a broadcast signal, wrapped in an interface. I don't think that how you pass it around makes any difference, including sending it over another channel.

Aside: it can be argued that "worker pool" is an anti-pattern in Go. Goroutines are so cheap that there's very little point in re-using them; you might as well just create one, let it do some work then terminate. Of course you want to limit the amount of *concurrent* work that is done, but there are other ways to achieve that. If there's stuff you need to keep around from task to task, like a persistent database connection, then maybe "worker pool" still makes sense.

This is covered in the talk "Rethinking Classical Concurrency Patterns" by Bryan C. Mills:

https://www.youtube.com/watch?v=5zXAHh5tJqQ

It's all well worth watching - keep the pause and rewind buttons under your fingers!  Code at 32:15 shows limiting concurrency amongst goroutines, giving worker-pool-like behaviour but without leaving idle goroutines lying around.