tunny alternatives and similar packages
Based on the "Goroutines" category.
Alternatively, view tunny alternatives based on common mentions on social networks and blogs.
-
ants
๐๐๐ ants is a high-performance and low-cost goroutine pool in Go./ ants ๆฏไธไธช้ซๆง่ฝไธไฝๆ่็ goroutine ๆฑ ใ -
goworker
goworker is a Go-based background worker that runs 10 to 100,000* times faster than Ruby-based workers. -
pond
๐ Minimalistic and High-performance goroutine worker pool written in Go -
pool
:speedboat: a limited consumer goroutine or unlimited goroutine pool for easier goroutine handling and cancellation -
Goflow
Simply way to control goroutines execution order based on dependencies -
artifex
Simple in-memory job queue for Golang using worker-based dispatching -
go-workers
๐ท Library for safely running groups of workers concurrently or consecutively that require input and output through channels -
async
A safe way to execute functions asynchronously, recovering them in case of panic. It also provides an error stack aiming to facilitate fail causes discovery. -
gollback
Go asynchronous simple function utilities, for managing execution of closures and callbacks -
semaphore
๐ฆ Semaphore pattern implementation with timeout of lock/unlock operations. -
Hunch
Hunch provides functions like: All, First, Retry, Waterfall etc., that makes asynchronous flow control more intuitive. -
go-do-work
Dynamically resizable pools of goroutines which can queue an infinite number of jobs. -
gpool
gpool - a generic context-aware resizable goroutines pool to bound concurrency based on semaphore. -
routine
go routine control, abstraction of the Main and some useful Executors.ๅฆๆไฝ ไธไผ็ฎก็Goroutine็่ฏ๏ผ็จๅฎ -
go-actor
A tiny library for writing concurrent programs in Go using actor model -
gowl
Gowl is a process management and process monitoring tool at once. An infinite worker pool gives you the ability to control the pool and processes and monitor their status. -
kyoo
Unlimited job queue for go, using a pool of concurrent workers processing the job queue entries -
go-waitgroup
A sync.WaitGroup with error handling and concurrency control -
channelify
Make functions return a channel for parallel processing via go routines. -
execpool
A pool that spins up a given number of processes in advance and attaches stdin and stdout when needed. Very similar to FastCGI but works for any command. -
conexec
A concurrent toolkit to help execute funcs concurrently in an efficient and safe way. It supports specifying the overall timeout to avoid blocking. -
hands
Hands is a process controller used to control the execution and return strategies of multiple goroutines. -
queue
package queue gives you a queue group accessibility. Helps you to limit goroutines, wait for the end of the all goroutines and much more. -
concurrency-limiter
Concurrency limiter with support for timeouts , dynamic priority and context cancellation of goroutines. -
async-job
AsyncJob is an asynchronous queue job manager with light code, clear and speed. I hope so ! ๐ฌ -
github.com/akshaybharambe14/gowp
High performance, type safe, concurrency limiting worker pool package for golang!
Access the most powerful time series database as a service
Do you think we are missing an alternative of tunny or a related project?
Popular Comparisons
README
[Tunny](tunny_logo.png "Tunny")
Tunny is a Golang library for spawning and managing a goroutine pool, allowing you to limit work coming from any number of goroutines with a synchronous API.
A fixed goroutine pool is helpful when you have work coming from an arbitrary number of asynchronous sources, but a limited capacity for parallel processing. For example, when processing jobs from HTTP requests that are CPU heavy you can create a pool with a size that matches your CPU count.
Install
go get github.com/Jeffail/tunny
Or, using dep:
dep ensure -add github.com/Jeffail/tunny
Use
For most cases your heavy work can be expressed in a simple func()
, where you
can use NewFunc
. Let's see how this looks using our HTTP requests to CPU count
example:
package main
import (
"io/ioutil"
"net/http"
"runtime"
"github.com/Jeffail/tunny"
)
func main() {
numCPUs := runtime.NumCPU()
pool := tunny.NewFunc(numCPUs, func(payload interface{}) interface{} {
var result []byte
// TODO: Something CPU heavy with payload
return result
})
defer pool.Close()
http.HandleFunc("/work", func(w http.ResponseWriter, r *http.Request) {
input, err := ioutil.ReadAll(r.Body)
if err != nil {
http.Error(w, "Internal error", http.StatusInternalServerError)
}
defer r.Body.Close()
// Funnel this work into our pool. This call is synchronous and will
// block until the job is completed.
result := pool.Process(input)
w.Write(result.([]byte))
})
http.ListenAndServe(":8080", nil)
}
Tunny also supports timeouts. You can replace the Process
call above to the
following:
result, err := pool.ProcessTimed(input, time.Second*5)
if err == tunny.ErrJobTimedOut {
http.Error(w, "Request timed out", http.StatusRequestTimeout)
}
You can also use the context from the request (or any other context) to handle timeouts and deadlines. Simply replace the Process
call to the following:
result, err := pool.ProcessCtx(r.Context(), input)
if err == context.DeadlineExceeded {
http.Error(w, "Request timed out", http.StatusRequestTimeout)
}
Changing Pool Size
The size of a Tunny pool can be changed at any time with SetSize(int)
:
pool.SetSize(10) // 10 goroutines
pool.SetSize(100) // 100 goroutines
This is safe to perform from any goroutine even if others are still processing.
Goroutines With State
Sometimes each goroutine within a Tunny pool will require its own managed state.
In this case you should implement tunny.Worker
, which includes
calls for terminating, interrupting (in case a job times out and is no longer
needed) and blocking the next job allocation until a condition is met.
When creating a pool using Worker
types you will need to provide a constructor
function for spawning your custom implementation:
pool := tunny.New(poolSize, func() Worker {
// TODO: Any per-goroutine state allocation here.
return newCustomWorker()
})
This allows Tunny to create and destroy Worker
types cleanly when the pool
size is changed.
Ordering
Backlogged jobs are not guaranteed to be processed in order. Due to the current implementation of channels and select blocks a stack of backlogged jobs will be processed as a FIFO queue. However, this behaviour is not part of the spec and should not be relied upon.