A goroutine pool library for Go that limits parallel processing with a synchronous API.
Tunny is a Go library that provides a goroutine pool implementation for managing concurrent workloads. It solves the problem of limiting parallel processing when work comes from arbitrary asynchronous sources but system capacity is constrained, such as when processing CPU-intensive HTTP requests.
Go developers building concurrent applications that need to throttle parallel execution, particularly those handling CPU-bound tasks from multiple goroutines or HTTP requests.
Developers choose Tunny for its simple synchronous API that abstracts goroutine management complexities, its support for timeouts and context integration, and its ability to dynamically resize pools at runtime without disrupting ongoing operations.
A goroutine pool for Go
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides blocking Process calls that abstract goroutine synchronization, making concurrent work coordination easy, as shown in the HTTP handler example where it blocks until job completion.
Includes ProcessTimed and ProcessCtx methods for precise timeout and deadline management, seamlessly integrating with Go's context package for cancellation.
Allows pool size to be changed on-the-fly with SetSize, even during active processing, without disrupting ongoing jobs, enabling adaptive resource management.
Supports implementing the tunny.Worker interface for goroutines with managed state, with clean lifecycle management via constructor functions, as detailed in the README.
The README explicitly states that backlogged jobs are not processed in order, which can be a significant limitation for applications requiring sequential processing.
Lacks built-in support for job prioritization, retry logic, or advanced error handling, forcing developers to implement these manually for complex workflows.
Creating custom workers requires implementing the tunny.Worker interface and managing state per goroutine, adding overhead compared to simpler function-based pools.