This library writes a Goroutine Pool. The author says the library will benefits the go’s performance. But in my opinion, Golang is already a M:N user-space thread, I think Go doesn’t need threadpool, except the user wants to maintanance priority for tasks.
So, I wonder:
Does Golang need a “Goroutine Pool”?
What can we benefits from a “Goroutine Pool”, and what will it lost?
But for some workloads in some projects, it might make sense to have a general worker pool implementation. The benefit is that the memory consumption can be limited by not allowing the number of goroutines to exceed whatever the pool allows, though I’m unsure of what order of magnitude of goroutines you need before that benefit is manifested.
Francesc Campoy created a fractal with 4 million goroutines (link) and it worked and scaled, but not perfectly. The issue wasn’t with the number of goroutines but that the runtime spent more time managing the goroutines than the goroutines actually worked. By giving the goroutines more work, (I think instead of each goroutine processing only one pixel, they processed the whole line?) the solution still scaled and ended up performing better.
Thank you! So for most parts, we can rely on Go runtime and not care about It. And if we really wants million of goroutine, we may need bench it and decide what to do?
In almost all cases (see below), you don’t need a pool.
There is one use case where a managing pool is feasible: guaranteed asynchronous executions via persistence memory. The pool’s main job is to save the tasks into persistent database execute them at its own pace and resources. In the event of app crashes or power blackout, the manager must be able to recover its last execution state and continue its work. That’s about it.
However, the said case is a very rare occasion. I only deployed once for my hobby project on Pi without depending on third-party module. You might need to check whether Ant supports said use case before applying it.