A Go worker pool library that limits concurrency of goroutine execution, supports timeouts, and never blocks task submission.
gowp is a Go library that implements a worker pool for managing and limiting the concurrency of goroutine execution. It solves the problem of uncontrolled goroutine spawning by providing a pool that limits simultaneous task execution while ensuring task submission is never blocked. The library includes features like timeout support, error propagation, and an optional rate limiter component.
Go developers building applications that require controlled concurrency, such as web servers, data processing pipelines, or any system needing to limit simultaneous goroutine execution to prevent resource exhaustion.
Developers choose gowp for its non-blocking task submission, straightforward API, and focus on execution concurrency limits rather than queue size limits. Its additional limiter component for rate limiting with Redis support provides extra utility beyond basic worker pool functionality.
golang worker pool , Concurrency limiting goroutine pool
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Tasks can be submitted without blocking, regardless of queue size, ensuring smooth ingestion even under high load, as emphasized in the README with 'Never blocks submitting tasks'.
Limits the number of concurrently executing goroutines to prevent resource exhaustion, with configurable pool size via the New() function, addressing core concurrency control needs.
Provides timeout settings with SetTimeout() and centralized error handling through task return values and Wait() method, demonstrated in the examples for robust task management.
Includes a limiter component with cache and Redis backends for rate limiting, adding versatility beyond the worker pool, as shown in the limiter examples.
Lacks advanced features like task cancellation, priority queues, or dynamic worker scaling, which are common in more comprehensive worker pool libraries.
Non-blocking submission can lead to unbounded queue growth if tasks are produced faster than consumed, risking high memory usage without explicit backpressure mechanisms.
Using the Redis backend for the limiter requires additional setup and dependency management, as seen in the Redis example, which adds deployment overhead.