Go: Worker Pool vs Pool of Workers

Have you ever seen pattern “worker pool” in programming language?
If you don’t let’s talk a little bit about it

Worker pool is a “pool” of thread or in Golang it’s goroutine should be considered as a worker, the term pool means we have several workers to do the job in synchronous or asynchronous form

So, what is the different between worker pool and pool of workers? Let’s see the implementations of two

Worker pool

A list of goroutines consume a single job queue and do the work

Pool of Workers

A list of gorountines which has it own job queue and whenever it’s free it will register it’s queue to a “worker queue”, Job handler need to consume the job queue from worker queue and push job into this job queue

Which is better?

Not Performance, not memory but controllable and timeout enable

What happen if you want to time out a job execution? With the first implementation it’s impossible, you can determine if when a job is picked because it depends on other job execution time in queue

With second implementation we have a nice and more explicit controllable timeout. Putting a timeout ticker before getting Job Channel from Worker Channel is the way we can control timeout for getting “in serving” position

Tips#1 : You can get timeout control with non-buffered channel in the first implementation

Tips#2 : This Repo already make an implementation (the second one) easy like a pie