How do I use Tunny to limit concurrent HTTP request processing in Go?

Create a pool with tunny.NewFunc matching CPU count, then call pool.Process in your HTTP handler to block until job completion, as shown in the README example. For timeouts, use ProcessTimed or ProcessCtx with context from requests.

Tunny vs native Go goroutines: which is better for my project?

Use Tunny when you need to limit parallel execution, such as for CPU-bound tasks or resource throttling. Native goroutines are sufficient for simple concurrency without pooling, but Tunny adds control over parallelism with a synchronous API.

Does Tunny support job cancellation and deadlines?

Yes, Tunny integrates with Go's context package through ProcessCtx for cancellation and deadlines. You can also use ProcessTimed for simple timeouts, making it flexible for handling job expiration.

How to handle errors in Tunny worker functions?

Error handling is developer-defined; the worker function should return errors as part of the interface, and Process methods return errors for timeouts. For custom errors, implement logic within the worker or use context cancellation.

What's the best way to determine pool size in Tunny?

For CPU-intensive tasks, set pool size to runtime.NumCPU() as recommended in the README. For I/O bound tasks, adjust based on system resources and workload, using SetSize for dynamic changes during runtime.

Can I use Tunny for I/O bound operations or is it only for CPU intensive work?

Tunny can be used for I/O bound tasks, but its fixed pool model is optimized for CPU parallelism. For I/O, you might need a larger pool size or consider other strategies, though the synchronous API still applies for coordination.

How to implement a custom worker with persistent state in Tunny?

Implement the tunny.Worker interface with Process, Interrupt, and Terminate methods, then use tunny.New with a constructor function that returns your custom worker, managing state per goroutine as described in the README.

Open-Awesome

tunny

MITGo

A goroutine pool library for Go that limits parallel processing with a synchronous API.

GitHub

4.0k stars305 forks0 contributors

What is tunny?

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.

Target Audience

Go developers building concurrent applications that need to throttle parallel execution, particularly those handling CPU-bound tasks from multiple goroutines or HTTP requests.

Value Proposition

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.

Overview

A goroutine pool for Go

Use Cases

Best For

Processing CPU-intensive HTTP requests with controlled parallelism
Throttling concurrent database operations in Go applications
Implementing worker pools for batch job processing
Managing resource usage in microservices handling variable loads
Creating fixed-size goroutine pools for predictable performance
Handling asynchronous workloads with synchronous coordination requirements

Not Ideal For

Projects requiring strict FIFO job ordering for sequential processing
Systems with highly dynamic workloads needing adaptive pooling algorithms beyond fixed-size resizing
Use cases demanding built-in job retry, prioritization, or complex scheduling features
Very simple concurrency tasks where vanilla goroutines without pooling suffice

Pros & Cons

Pros

Synchronous API Simplicity

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.

Robust Timeout Handling

Includes ProcessTimed and ProcessCtx methods for precise timeout and deadline management, seamlessly integrating with Go's context package for cancellation.

Dynamic Runtime Adjustment

Allows pool size to be changed on-the-fly with SetSize, even during active processing, without disrupting ongoing jobs, enabling adaptive resource management.

Custom Stateful Workers

Supports implementing the tunny.Worker interface for goroutines with managed state, with clean lifecycle management via constructor functions, as detailed in the README.

Cons

No Job Order Guarantee

The README explicitly states that backlogged jobs are not processed in order, which can be a significant limitation for applications requiring sequential processing.

Missing Advanced Features

Lacks built-in support for job prioritization, retry logic, or advanced error handling, forcing developers to implement these manually for complex workflows.

Setup Complexity for Stateful Use

Creating custom workers requires implementing the tunny.Worker interface and managing state per goroutine, adding overhead compared to simpler function-based pools.

Frequently Asked Questions

Related Projects

ants

🐜🐜🐜 ants is the most powerful and reliable pooling solution for Go.

Stars14,526

Forks1,442

Last commit1 month ago

conc

Better structured concurrency for go

Stars10,435

Forks366

Last commit1 month ago

goworker

goworker is a Go-based background worker that runs 10 to 100,000* times faster than Ruby-based workers.

Stars2,847

Forks242

Last commit28 days ago

pond

🔘 Minimalistic and High-performance goroutine worker pool written in Go

Stars2,199

Forks93

Last commit6 days ago

Community-curated · Updated weekly · 100% open source

Found a gem we're missing?

Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.

Submit a project Star on GitHub