tunny — Middle Level¶

Table of Contents¶

1. Introduction
2. Prerequisites
3. Glossary
4. The Worker Interface
5. Why an Interface and Not Just a Function
6. Process — Recap and Refinement
7. BlockUntilReady — Throttling Acceptance
8. Interrupt — Server-Side Cancellation
9. Terminate — Worker Shutdown
10. tunny.New — Worker Factories
11. ProcessTimed — Deadlines per Call
12. ProcessCtx — Context-Aware Cancellation
13. tunny.NewCallback — Free-Form Closures
14. State, Reuse, and the Worker Lifecycle
15. Pool Sizing Revisited
16. Worked Examples
17. Patterns
18. Clean Code
19. Error Handling
20. Performance Tips
21. Best Practices
22. Edge Cases and Pitfalls
23. Common Mistakes
24. Common Misconceptions
25. Tricky Points
26. Test Yourself
27. Tricky Questions
28. Cheat Sheet
29. Self-Assessment Checklist
30. Summary
31. What You Can Build Now
32. Further Reading
33. Related Topics
34. Diagrams

Introduction¶

Focus: "How do I give each worker its own state, enforce a deadline on each call, propagate a context, and decide between the three constructors?"

At the junior level you treated tunny as a single function: NewFunc(n, f). That works for many real workloads, but it has three serious limits:

1. The worker function is stateless — there is no way to give each of the n workers a private buffer, a decoder, a database connection, or a model loaded in memory.
2. There is no way to cancel an in-flight call. If Process is waiting and the caller wants to give up, it cannot.
3. There is no way for a worker to refuse to accept more work — for example, when a downstream rate limit has not yet replenished.

The middle level introduces the Worker interface, which solves all three. You will also learn the deadline-aware variants ProcessTimed and ProcessCtx, and the convenience constructor NewCallback.

After this file you should be able to:

• Define a Worker type for a stateful workload (e.g. an image decoder with reusable buffers).
• Choose the right constructor (NewFunc vs New vs NewCallback) for a given problem.
• Use ProcessTimed and ProcessCtx correctly, understanding what they actually do.
• Implement BlockUntilReady for downstream backpressure.
• Implement Interrupt so cancellation reaches the worker.
• Build a typed wrapper over the middle-level API that hides the any plumbing.

Prerequisites¶

• Comfortable with everything in junior.md. If you cannot reproduce the parallel SHA-256 example from memory, go back.
• Familiar with interfaces in Go, especially how to satisfy an interface implicitly with a struct.
• Familiar with context.Context — at least context.WithTimeout, context.WithCancel, and how to check ctx.Err().
• Familiar with time.Duration and time.After or time.NewTimer.
• Familiar with sync.Pool — the standard-library object pool. We use it together with tunny.
• Familiar with sync.Mutex and sync/atomic for protecting worker-local state.

If you are weak on context.Context, take a detour to that chapter. The middle-level tunny API is mostly about plumbing cancellation; you need a feel for how Go does that idiomatically.

Glossary¶

The Worker Interface¶

This is the interface that tunny's machinery is built around:

package tunny

type Worker interface {
    // Process is called by the pool with the payload from a Process call.
    // The return value becomes the result of the original Process call.
    Process(payload interface{}) interface{}

    // BlockUntilReady is called *before* Process. It can block to apply
    // backpressure: a worker can refuse to accept work until a downstream
    // resource is available.
    BlockUntilReady()

    // Interrupt is called when a ProcessTimed deadline elapses or a
    // ProcessCtx context is cancelled while the worker is mid-call.
    // The worker should use this to abort cooperatively.
    Interrupt()

    // Terminate is called once when the pool is closed. The worker
    // should release any owned resources here.
    Terminate()
}

Four methods, no generics, no hidden state. The Go interface in its purest form.

To create a pool, you write a struct that satisfies this interface, then a factory:

type myWorker struct {
    // per-worker state here
}

func (w *myWorker) Process(p interface{}) interface{} { ... }
func (w *myWorker) BlockUntilReady()                  {}
func (w *myWorker) Interrupt()                        {}
func (w *myWorker) Terminate()                        {}

pool := tunny.New(runtime.NumCPU(), func() tunny.Worker {
    return &myWorker{}
})
defer pool.Close()

That is the whole shape. The methods you do not need can be empty.

Why an Interface and Not Just a Function¶

This is a design choice worth pausing on. Other pool libraries (notably ants) take a closure on Submit. Tunny takes an object on New. Why?

Three reasons:

1. Per-worker state is first-class¶

If your worker needs an expensive resource — a 200 MB ML model, a database connection, a buffered codec — you want to create it once per worker and reuse it across many calls. With a closure-on-submit model, you would have to either share the resource across goroutines (more locking) or recreate it per call (wasted work). With a method on a struct, the resource lives naturally in a field.

type modelWorker struct {
    model *ml.Model  // loaded once, used for thousands of inferences
    buf   bytes.Buffer
}

func (w *modelWorker) Process(p interface{}) interface{} {
    req := p.(InferReq)
    w.buf.Reset()
    return w.model.Predict(req, &w.buf)
}

That model field is the entire reason tunny.New exists.

2. Cancellation has a hook¶

A bare function cannot be cancelled — the runtime cannot reach into a running function and stop it. But a struct with an Interrupt method can be notified: "you should stop". Whether the worker actually stops is up to the worker's implementation — it can poll a flag, close a sub-context, or do nothing if cancellation is not meaningful.

3. Backpressure is symmetric¶

Junior tunny gives backpressure to the caller (the pool channel is bounded by n). Middle tunny adds the dual: workers can apply backpressure too, via BlockUntilReady. This is essential when the bottleneck is downstream of the worker — a rate-limited API, a quota'd cloud service, a slow database.

These three powers are unlocked only by promoting "the worker" from a function to an object. The cost — a few more lines of boilerplate — is small compared to the flexibility.

Process — Recap and Refinement¶

Process on the Worker interface is the same idea as the function passed to NewFunc:

func (w *Worker) Process(payload interface{}) interface{}

It is called by the pool when a payload has been assigned to this worker. It runs in the worker's goroutine. It must:

• Be deterministic given the payload (no hidden state with surprising effects).
• Be safe to call repeatedly — many Process calls per worker over the worker's lifetime.
• Not block forever — pair every potentially-blocking operation with a way to interrupt.

It must NOT:

• Spawn long-lived goroutines without tying them to the worker's lifetime.
• Hold locks across calls (locks should be acquired and released within one Process invocation).
• Touch state that another worker also touches, unless that state is synchronised.

A canonical Process:

func (w *imageWorker) Process(p interface{}) interface{} {
    req := p.(ResizeReq)
    w.buf.Reset()                // reuse worker-local buffer
    img, err := decode(req.Data, &w.buf)
    if err != nil {
        return ResizeRes{Err: err}
    }
    out, err := resize(img, req.W, req.H)
    if err != nil {
        return ResizeRes{Err: err}
    }
    return ResizeRes{Image: out}
}

Each Process does the same kind of work, with the same input/output shape, against the same worker-local buffer.

BlockUntilReady — Throttling Acceptance¶

BlockUntilReady is called by the pool before Process is called. The pool guarantees: "I have a payload for you. Are you ready?" The worker can:

• Return immediately (the default behaviour — empty method).
• Block for any amount of time until it is willing to accept.

Why is this useful? Consider three scenarios.

Scenario A — token bucket rate limit¶

The downstream service allows 10 requests per second. Without BlockUntilReady, you would need a rate limiter inside Process, where it adds latency after the worker has already been assigned. With BlockUntilReady, the worker simply does not raise its hand until a token is available — leaving the pool free to dispatch elsewhere.

type rateLimitedWorker struct {
    lim *rate.Limiter
}

func (w *rateLimitedWorker) BlockUntilReady() {
    _ = w.lim.Wait(context.Background())
}

func (w *rateLimitedWorker) Process(p interface{}) interface{} {
    // ... no token check needed; we already have one
    return callDownstream(p)
}

Scenario B — GPU slot¶

One GPU, four workers, each worker can only run when the GPU is free.

type gpuWorker struct {
    gpuSem chan struct{}  // buffered, size 1, shared across workers
    gpu    *GPUDevice
}

func (w *gpuWorker) BlockUntilReady() {
    w.gpuSem <- struct{}{} // acquire
}

func (w *gpuWorker) Process(p interface{}) interface{} {
    defer func() { <-w.gpuSem }() // release
    return w.gpu.Run(p)
}

Note: the semaphore is shared across worker instances. Workers do not share Process state, but they can share orthogonal resources.

Scenario C — circuit breaker¶

If a circuit breaker is open, do not accept work:

func (w *circuitWorker) BlockUntilReady() {
    for {
        if w.breaker.State() == "closed" {
            return
        }
        time.Sleep(100 * time.Millisecond)
    }
}

Better: use a context-aware wait, but you get the idea.

When to leave BlockUntilReady empty¶

For most CPU-bound workers without external rate limits, the method is empty. Do not add a BlockUntilReady "just in case" — leave it empty until you have a concrete reason.

Interrupt — Server-Side Cancellation¶

Interrupt is the pool's way of telling the worker: "the caller has given up; stop if you can."

It is invoked by tunny:

• When a ProcessTimed deadline elapses while the worker is mid-call.
• When a ProcessCtx context is cancelled while the worker is mid-call.

Interrupt runs in a different goroutine from Process — typically the goroutine that was waiting on the result. So it must be safe to call concurrently with Process.

Implementations vary:

Pattern 1 — atomic flag¶

The worker checks a flag periodically inside Process:

type cancellableWorker struct {
    stop atomic.Bool
}

func (w *cancellableWorker) Process(p interface{}) interface{} {
    w.stop.Store(false)
    n := p.(int)
    sum := 0
    for i := 0; i < n; i++ {
        if w.stop.Load() {
            return -1
        }
        sum += slowOp(i)
    }
    return sum
}

func (w *cancellableWorker) Interrupt() {
    w.stop.Store(true)
}

This is the most flexible pattern. The granularity of cancellation is whatever you choose: every iteration, every 1000 iterations, every second.

Pattern 2 — close a per-call channel¶

type cancellableWorker struct {
    cancel chan struct{}
}

func (w *cancellableWorker) Process(p interface{}) interface{} {
    w.cancel = make(chan struct{})
    select {
    case <-time.After(5 * time.Second):
        return "done"
    case <-w.cancel:
        return "cancelled"
    }
}

func (w *cancellableWorker) Interrupt() {
    close(w.cancel)
}

Beware: if Interrupt is called after Process returns, close on a stale channel panics. Guard with sync.Once or a state machine.

Pattern 3 — cancel a sub-context¶

If your worker does its work via a function that takes a context.Context, the cleanest pattern:

type ctxWorker struct {
    mu     sync.Mutex
    cancel context.CancelFunc
}

func (w *ctxWorker) Process(p interface{}) interface{} {
    ctx, cancel := context.WithCancel(context.Background())
    w.mu.Lock()
    w.cancel = cancel
    w.mu.Unlock()
    defer cancel()

    return doWork(ctx, p)
}

func (w *ctxWorker) Interrupt() {
    w.mu.Lock()
    if w.cancel != nil {
        w.cancel()
    }
    w.mu.Unlock()
}

This is the production pattern for any worker whose underlying functions accept a context.Context. We will see in ProcessCtx that you should propagate the caller's context where possible — but the above shape is the right skeleton.

When Interrupt is a no-op¶

For a truly atomic operation that cannot be interrupted mid-way — say, a CGo call into a synchronous C library — Interrupt cannot do anything. Leave the method empty. The deadline will fire from the caller's perspective, the worker will finish naturally a bit later, and the worker's result will be discarded by tunny.

That last sentence is important: even if Interrupt is a no-op, the deadline still fires correctly from the caller's side. The worker just keeps wasting CPU until it returns. So while a no-op Interrupt is legal, it is wasteful.

Terminate — Worker Shutdown¶

Terminate is called exactly once on each worker, when the pool is closed. The worker should:

• Close any owned files.
• Close any owned network connections.
• Free any large buffers (let GC happen sooner).
• Stop any goroutines the worker spawned (rare, but possible).

Example:

type dbWorker struct {
    conn *sql.Conn
}

func (w *dbWorker) Terminate() {
    if w.conn != nil {
        _ = w.conn.Close()
    }
}

Terminate is not called when the worker is busy. The pool waits for the worker to finish its current Process before calling Terminate. So you do not have to defend against racing with Process.

What you must defend against: Terminate is called once. Make it idempotent if you can. Setting fields to nil after closing them is a small defensive habit:

func (w *dbWorker) Terminate() {
    if w.conn != nil {
        _ = w.conn.Close()
        w.conn = nil
    }
}

This protects against future code paths that might accidentally call Terminate again.

tunny.New — Worker Factories¶

The full constructor:

func New(n int, ctor func() Worker) *Pool

ctor is the factory. It is called n times, once for each worker slot. Each call should return a fresh, independent Worker instance.

A typical factory:

func newImageWorker() tunny.Worker {
    return &imageWorker{
        buf: make([]byte, 0, 64*1024),
    }
}

pool := tunny.New(runtime.NumCPU(), newImageWorker)

The factory may panic if construction fails. The panic will propagate out of tunny.New. So fail-fast initialisation (cannot load model, cannot open file) is fine in the factory — your program crashes at startup, which is what you want for fatal config errors.

What the factory does NOT do:

• It does not run on every Process call. Only at pool construction (and on SetSize for the new slots).
• It does not run in a goroutine you control. Tunny calls it from the goroutine that called New.
• It does not need to be reentrant — it is called sequentially.

A common subtle bug: capturing a shared resource by reference, then mutating it in each factory call:

// WRONG
shared := &Config{}
pool := tunny.New(4, func() tunny.Worker {
    shared.WorkerID++  // ???
    return &worker{cfg: shared}
})

All four workers end up with the same cfg pointer; the WorkerID counter is shared via that pointer. If you wanted independent IDs, you needed to take a copy or pass a value, not a pointer.

The right shape is to pass values, not shared pointers, unless sharing is intentional:

var nextID atomic.Int64
pool := tunny.New(4, func() tunny.Worker {
    return &worker{id: nextID.Add(1)}
})

ProcessTimed — Deadlines per Call¶

func (p *Pool) ProcessTimed(payload interface{}, timeout time.Duration) (interface{}, error)

ProcessTimed is like Process but with a deadline. If the deadline elapses, it returns tunny.ErrJobTimedOut and the result is discarded.

Critical: there are two phases during which the timeout matters:

1. Waiting for a worker. If all workers are busy, the caller is queued. The deadline ticks during this wait.
2. Worker is running. Once a worker has been assigned, the deadline continues to tick.

In both phases, the timeout is total. So ProcessTimed(x, 5*time.Second) means "give me a result or an error within 5 seconds total."

If the timeout fires during phase 1 (waiting), the caller gets the error without ever having dispatched the payload. No worker runs.

If the timeout fires during phase 2 (worker is running), tunny calls Interrupt() on the worker. The worker is expected to abort cooperatively. Tunny returns the error to the caller. The worker's eventual return value is discarded.

Example:

result, err := pool.ProcessTimed(req, 200*time.Millisecond)
if err == tunny.ErrJobTimedOut {
    return ErrSlow
}
if err == tunny.ErrPoolNotRunning {
    return ErrShuttingDown
}
return result.(MyResult), nil

Two distinct errors. Handle both. There are no others (today).

Timeout granularity¶

time.Duration is nanosecond precision. Tunny does not promise nanosecond-precision deadlines — under load, deadline detection is typically within a few hundred microseconds. For most workloads this is more than precise enough.

What Interrupt actually does when timeout fires¶

A subtlety: tunny calls Interrupt once, immediately when the timeout fires. The worker's Process is still running. The worker's Process might or might not honour the interrupt. If it does not, the worker just continues running. The caller already has its error and has moved on. The pool will not give that worker a new payload until Process finally returns. Meanwhile other workers are still serving traffic.

This is "graceful, eventually." The worker that was running a timed-out job is effectively a write-off until its current call completes. If you have many calls timing out, you can starve the pool. Plan timeouts to be longer than the typical work duration.

ProcessCtx — Context-Aware Cancellation¶

func (p *Pool) ProcessCtx(ctx context.Context, payload interface{}) (interface{}, error)

ProcessCtx is the context-aware counterpart of ProcessTimed. It returns when either:

• The worker finishes its Process — you get (result, nil).
• ctx.Done() closes — you get (nil, ctx.Err()). Internally, Interrupt() is invoked on the worker.

In modern Go, this is the preferred shape, because context.Context carries more than just a deadline — it can be cancelled by the caller for any reason (user clicked stop, parent operation aborted, etc).

Example:

ctx, cancel := context.WithTimeout(r.Context(), 200*time.Millisecond)
defer cancel()
result, err := pool.ProcessCtx(ctx, req)
if err != nil {
    if errors.Is(err, context.DeadlineExceeded) {
        return ErrSlow
    }
    if errors.Is(err, context.Canceled) {
        return ErrClientGone
    }
    if errors.Is(err, tunny.ErrPoolNotRunning) {
        return ErrShuttingDown
    }
    return err
}
return result.(MyResult), nil

ProcessCtx is what you should use in HTTP handlers. The request's context (via r.Context()) already encodes the client's lifetime; passing it to ProcessCtx means client disconnect propagates all the way to the worker.

When ctx already has a deadline¶

ProcessCtx honours whatever cancellation behaviour the context has. There is no separate timeout argument. If the caller wants a timeout, they put it in the context. This is the idiomatic Go shape.

What if Process does not honour Interrupt?¶

Same as before. The caller gets the error immediately. The worker keeps running. Eventually the worker finishes and is returned to the pool. You have effectively rented out a worker for the duration of the (now-discarded) operation.

The lesson: if you use ProcessCtx or ProcessTimed, you owe yourself a thoughtful Interrupt implementation. Otherwise you have given the caller an SLA you did not give the worker.

tunny.NewCallback — Free-Form Closures¶

The third constructor:

func NewCallback(n int) *Pool

NewCallback creates a pool whose payload is a func(). The worker just calls it.

pool := tunny.NewCallback(runtime.NumCPU())
defer pool.Close()

pool.Process(func() {
    fmt.Println("hello from a callback")
})

When to use:

• Lots of small, independent CPU-bound tasks with different shapes.
• You do not want to define a payload type for each.
• You do not need a result back (the callback's return value is discarded).

When NOT to use:

• You need a typed return value (use NewFunc or New).
• You need cancellation (callbacks do not see deadlines).
• You care about avoiding closure allocation per call (every payload is a new closure).

In practice, NewCallback is more of a curiosity than a workhorse. You will likely use NewFunc or New for almost every real workload.

A concrete example where NewCallback makes sense:

pool := tunny.NewCallback(runtime.NumCPU())
defer pool.Close()

// Many heterogeneous one-off tasks.
var wg sync.WaitGroup
for _, task := range tasks {
    task := task
    wg.Add(1)
    pool.Process(func() {
        defer wg.Done()
        task.Run()
    })
}
wg.Wait()

The wg.Done lives inside the closure. The closure's signature is rigid (func()) so all coordination must be inside it.

State, Reuse, and the Worker Lifecycle¶

Each worker is created once, used many times, destroyed once. Visually:

              construct (ctor())
                     │
                     ▼
                  ┌──────┐
            ┌────▶│ Idle │◀────┐
            │     └──────┘     │
   BlockUntilReady             │
            │                  │
            ▼                  │
       ┌─────────┐             │
       │ Process │─── return ──┘
       └─────────┘
            │
            └── (on pool close, after current Process)
                     │
                     ▼
                Terminate()

The Idle → BlockUntilReady → Process → Idle loop runs many times. Then exactly one Terminate at the end.

This shape is similar to a Java thread-pool worker, a Tokio task, a CLR thread-pool work item. The names differ; the lifecycle is universal.

State across calls¶

The worker struct's fields are private to that worker. You can mutate them freely inside Process without locks, as long as nothing else touches them. (Note: Interrupt and Terminate run in different goroutines — if they read the same fields, you need synchronisation.)

A typical pattern:

type worker struct {
    // Process-only state: no locks needed.
    buf  []byte
    enc  *json.Encoder

    // Shared with Interrupt: needs synchronisation.
    mu     sync.Mutex
    cancel context.CancelFunc

    // Shared with Terminate: needs synchronisation (or only-once semantics).
    closed atomic.Bool
}

Discipline yourself: every field has exactly one "owner" set of methods. Document who can touch each field.

Pool Sizing Revisited¶

At the middle level, sizing decisions become a bit richer:

• For pure CPU-bound work without external constraints: runtime.NumCPU().
• For workers that wait on a downstream resource (rate limiter, GPU, database): size = max parallelism allowed by the downstream. There is no point having more workers than slots.
• For workers that mix CPU and IO: 2 * runtime.NumCPU() is a defensible default; measure.
• For workers with very large per-worker memory: smaller is better. If each worker holds a 500 MB model, you may have n = 2 on a 1 GB box even with 16 cores.

A useful framing: pool size = min(CPU cores, downstream parallelism, memory budget / per-worker footprint).

Three constraints, one of them is the bottleneck, that one sets n.

Worked Examples¶

Example 1 — image worker with reusable buffer¶

package main

import (
    "bytes"
    "image"
    _ "image/jpeg"
    "image/png"
    "log"
    "os"
    "path/filepath"
    "runtime"
    "sync"

    "github.com/Jeffail/tunny"
    "golang.org/x/image/draw"
)

type ResizeJob struct {
    InPath, OutPath string
    W, H            int
}

type ResizeResult struct {
    Path string
    Err  error
}

type imageWorker struct {
    buf bytes.Buffer
}

func (w *imageWorker) Process(p interface{}) interface{} {
    job := p.(ResizeJob)
    f, err := os.Open(job.InPath)
    if err != nil {
        return ResizeResult{Path: job.InPath, Err: err}
    }
    defer f.Close()

    w.buf.Reset()
    if _, err := w.buf.ReadFrom(f); err != nil {
        return ResizeResult{Path: job.InPath, Err: err}
    }
    src, _, err := image.Decode(&w.buf)
    if err != nil {
        return ResizeResult{Path: job.InPath, Err: err}
    }

    dst := image.NewRGBA(image.Rect(0, 0, job.W, job.H))
    draw.CatmullRom.Scale(dst, dst.Bounds(), src, src.Bounds(), draw.Over, nil)

    out, err := os.Create(job.OutPath)
    if err != nil {
        return ResizeResult{Path: job.InPath, Err: err}
    }
    defer out.Close()
    if err := png.Encode(out, dst); err != nil {
        return ResizeResult{Path: job.InPath, Err: err}
    }
    return ResizeResult{Path: job.InPath}
}

func (w *imageWorker) BlockUntilReady() {}
func (w *imageWorker) Interrupt()       {}
func (w *imageWorker) Terminate()       {}

func main() {
    inputs, _ := filepath.Glob("input/*.jpg")
    pool := tunny.New(runtime.NumCPU(), func() tunny.Worker {
        return &imageWorker{}
    })
    defer pool.Close()

    var wg sync.WaitGroup
    for _, in := range inputs {
        in := in
        out := filepath.Join("output", filepath.Base(in)+".png")
        wg.Add(1)
        go func() {
            defer wg.Done()
            r := pool.Process(ResizeJob{in, out, 128, 128}).(ResizeResult)
            if r.Err != nil {
                log.Printf("resize %s: %v", r.Path, r.Err)
            }
        }()
    }
    wg.Wait()
}

Notice: the bytes.Buffer lives on the worker. Across thousands of calls, it grows once to the size of the largest JPEG and stays that size, eliminating GC pressure from re-allocating buffers per call.

Example 2 — cancellable worker¶

type cancellableWorker struct {
    mu     sync.Mutex
    cancel context.CancelFunc
}

func (w *cancellableWorker) Process(p interface{}) interface{} {
    ctx, cancel := context.WithCancel(context.Background())
    w.mu.Lock()
    w.cancel = cancel
    w.mu.Unlock()
    defer func() {
        w.mu.Lock()
        w.cancel = nil
        w.mu.Unlock()
        cancel()
    }()

    return slowWork(ctx, p)
}

func (w *cancellableWorker) BlockUntilReady() {}

func (w *cancellableWorker) Interrupt() {
    w.mu.Lock()
    if w.cancel != nil {
        w.cancel()
    }
    w.mu.Unlock()
}

func (w *cancellableWorker) Terminate() {}

func slowWork(ctx context.Context, p any) any {
    select {
    case <-time.After(2 * time.Second):
        return "done"
    case <-ctx.Done():
        return ctx.Err().Error()
    }
}

Use with ProcessCtx:

pool := tunny.New(4, func() tunny.Worker { return &cancellableWorker{} })
defer pool.Close()

ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()

r, err := pool.ProcessCtx(ctx, "hello")
fmt.Println(r, err) // "context deadline exceeded" via slowWork; err is ctx.Err()

When the timeout fires, tunny calls Interrupt, which cancels the worker's inner context, which unblocks the select in slowWork, which returns. The caller receives ctx.Err() as err.

Example 3 — rate-limited downstream¶

import (
    "context"
    "fmt"
    "net/http"
    "sync"
    "time"

    "github.com/Jeffail/tunny"
    "golang.org/x/time/rate"
)

type apiWorker struct {
    client *http.Client
    lim    *rate.Limiter
}

func (w *apiWorker) BlockUntilReady() {
    _ = w.lim.Wait(context.Background())
}

func (w *apiWorker) Process(p interface{}) interface{} {
    url := p.(string)
    resp, err := w.client.Get(url)
    if err != nil {
        return err
    }
    resp.Body.Close()
    return resp.StatusCode
}

func (w *apiWorker) Interrupt() {}
func (w *apiWorker) Terminate() {}

func main() {
    sharedLimiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 1) // 10 req/s
    sharedClient := &http.Client{Timeout: 5 * time.Second}

    pool := tunny.New(8, func() tunny.Worker {
        return &apiWorker{client: sharedClient, lim: sharedLimiter}
    })
    defer pool.Close()

    urls := []string{ /* 100 URLs */ }
    var wg sync.WaitGroup
    for _, u := range urls {
        u := u
        wg.Add(1)
        go func() {
            defer wg.Done()
            switch v := pool.Process(u).(type) {
            case int:
                fmt.Println(u, "->", v)
            case error:
                fmt.Println(u, "err:", v)
            }
        }()
    }
    wg.Wait()
}

Eight workers, but all share one limiter. The pool's "8" caps the latency parallelism; the limiter's "10 req/s" caps the throughput. Both constraints are honoured.

Example 4 — pool with a DB connection per worker¶

type dbWorker struct {
    db *sql.DB
}

func (w *dbWorker) Process(p interface{}) interface{} {
    q := p.(string)
    var out string
    err := w.db.QueryRow(q).Scan(&out)
    if err != nil {
        return err
    }
    return out
}

func (w *dbWorker) BlockUntilReady() {}
func (w *dbWorker) Interrupt()       {}
func (w *dbWorker) Terminate()       { _ = w.db.Close() }

func main() {
    pool := tunny.New(4, func() tunny.Worker {
        db, err := sql.Open("postgres", "...")
        if err != nil {
            panic(err)
        }
        return &dbWorker{db: db}
    })
    defer pool.Close()
    // use pool.Process(...)
}

A minor concern: sql.DB is itself a connection pool. Wrapping it inside another pool is sometimes unnecessary. But if your "work" is more than a single query — say, a multi-statement transaction with intermediate logic — a tunny worker around a DB cursor can simplify the code.

Example 5 — generic typed wrapper at the middle level¶

type Pool[In, Out any] struct {
    inner *tunny.Pool
}

type WorkerFunc[In, Out any] interface {
    Process(In) Out
    Interrupt()
    Terminate()
}

func New[In, Out any](n int, factory func() WorkerFunc[In, Out]) *Pool[In, Out] {
    return &Pool[In, Out]{
        inner: tunny.New(n, func() tunny.Worker {
            return &adapter[In, Out]{w: factory()}
        }),
    }
}

type adapter[In, Out any] struct {
    w WorkerFunc[In, Out]
}

func (a *adapter[In, Out]) Process(p interface{}) interface{} {
    return a.w.Process(p.(In))
}
func (a *adapter[In, Out]) BlockUntilReady() {}
func (a *adapter[In, Out]) Interrupt()       { a.w.Interrupt() }
func (a *adapter[In, Out]) Terminate()       { a.w.Terminate() }

func (p *Pool[In, Out]) Process(in In) Out {
    return p.inner.Process(in).(Out)
}
func (p *Pool[In, Out]) Close() { p.inner.Close() }

Now the caller writes:

type myW struct{}
func (myW) Process(n int) int { return n * 2 }
func (myW) Interrupt()        {}
func (myW) Terminate()        {}

p := New[int, int](4, func() WorkerFunc[int, int] { return myW{} })
defer p.Close()
fmt.Println(p.Process(7)) // 14

This is the production-grade shape. The interface{} is invisible. The compiler enforces types.

Patterns¶

Pattern: worker with retryable Interrupt¶

Sometimes Interrupt may be called multiple times for one Process. To be safe, idempotent:

func (w *worker) Interrupt() {
    w.mu.Lock()
    defer w.mu.Unlock()
    if w.cancel != nil {
        w.cancel()
        w.cancel = nil
    }
}

Pattern: composite worker¶

Some workers internally orchestrate sub-workers. A simple example:

type pipelineWorker struct {
    decode *imageWorker
    resize *resizeWorker
    encode *encodeWorker
}

func (w *pipelineWorker) Process(p interface{}) interface{} {
    img := w.decode.Process(p)
    if err, ok := img.(error); ok {
        return err
    }
    resized := w.resize.Process(img)
    if err, ok := resized.(error); ok {
        return err
    }
    return w.encode.Process(resized)
}

Note: the sub-workers here are NOT in their own tunny pools. They are plain types reused inside the orchestrating worker. The shape is fine, but you have lost compile-time clarity about which step is "expensive". Use it sparingly.

Pattern: optional interface satisfaction¶

If you only need Process and the other methods are always empty, define a helper:

type emptyHooks struct{}

func (emptyHooks) BlockUntilReady() {}
func (emptyHooks) Interrupt()       {}
func (emptyHooks) Terminate()       {}

type quickWorker struct {
    emptyHooks
    // ... real fields
}

This is a tiny ergonomics win — embedding a type that satisfies three of the four methods. Common in libraries that wrap tunny.

Pattern: per-call cancellation propagation¶

When using ProcessCtx, your worker should ideally accept a context.Context for the actual work. Wire it through:

type ctxAware struct {
    mu     sync.Mutex
    cancel context.CancelFunc
}

func (w *ctxAware) Process(p interface{}) interface{} {
    ctx, cancel := context.WithCancel(context.Background())
    w.mu.Lock()
    w.cancel = cancel
    w.mu.Unlock()
    defer cancel()
    return doWork(ctx, p)
}

func (w *ctxAware) Interrupt() {
    w.mu.Lock()
    if w.cancel != nil {
        w.cancel()
    }
    w.mu.Unlock()
}

func (w *ctxAware) BlockUntilReady() {}
func (w *ctxAware) Terminate()       {}

This is the most robust shape for production workers. Anything that respects ctx.Done() is automatically cancellable.

Pattern: encoding deadlines in the payload¶

If you want to give each call its own deadline without using ProcessTimed, pack it into the payload:

type Job struct {
    Deadline time.Time
    Data     []byte
}

func (w *worker) Process(p interface{}) interface{} {
    j := p.(Job)
    if time.Now().After(j.Deadline) {
        return ErrDeadline
    }
    // ... do work, periodically check time.Now().After(j.Deadline)
}

This loses the pool-level wait timeout but gives you fine-grained, payload-driven deadlines.

Clean Code¶

A few habits that pay off at the middle level:

• Group method definitions on the worker together. All four Worker methods next to each other, in the canonical order (Process, BlockUntilReady, Interrupt, Terminate). Reviewers expect this order.
• Document fields by lifetime. Comment each field with which methods read or write it.
• Keep the worker struct flat. If you have nested structs with logic, you have a sub-system and not a worker. Refactor.
• Name the worker type after the workload, not the library. imageWorker, not tunnyWorker. The fact that tunny is the transport is an implementation detail.
• Hide the tunny.Pool behind a typed wrapper at module boundaries. Internally you may use *tunny.Pool directly; externally, expose a typed interface.
• Use BlockUntilReady only when you actually need it. An empty BlockUntilReady is fine and expected.

Error Handling¶

The middle API gives you two real error returns:

• tunny.ErrJobTimedOut from ProcessTimed.
• tunny.ErrPoolNotRunning from ProcessTimed and ProcessCtx after Close.

ProcessCtx also returns ctx.Err() — either context.DeadlineExceeded or context.Canceled — when the context fires before the worker finishes.

Standard handling:

result, err := pool.ProcessCtx(ctx, req)
switch {
case errors.Is(err, context.DeadlineExceeded):
    metrics.Inc("pool.timeout")
    return ErrTimeout
case errors.Is(err, context.Canceled):
    metrics.Inc("pool.cancelled")
    return ErrCancelled
case errors.Is(err, tunny.ErrPoolNotRunning):
    metrics.Inc("pool.closed")
    return ErrShuttingDown
case err != nil:
    return fmt.Errorf("unexpected pool error: %w", err)
}
// success
return result.(MyResult), nil

Anything else returned is an unexpected error. Always handle the catch-all.

Worker-side errors¶

Inside the worker, the Process method has no error return — it returns any. The convention is to encode errors in the result struct:

type res struct {
    Out string
    Err error
}

Or, in some codebases, return either a result value or an error:

func (w *worker) Process(p any) any {
    out, err := doWork(p)
    if err != nil {
        return err
    }
    return out
}

The caller then does:

switch v := r.(type) {
case error:
    handleErr(v)
case Result:
    handle(v)
default:
    panic(fmt.Sprintf("unexpected: %T", v))
}

The switch v := r.(type) pattern is fine but every callsite has to remember to handle errors. The result struct pattern is more disciplined.

Performance Tips¶

Mid-level performance levers:

1. Reuse buffers on the worker struct. This is the #1 reason to use tunny.New over NewFunc. A 50 KB buffer reused across 100k calls saves ~5 GB of allocation. GC pressure plummets.
2. Minimise per-call allocations inside Process. Profile with pprof — any line that allocates is a candidate for hoisting to a worker field.
3. Beware of contention in BlockUntilReady. A rate.Limiter shared across workers requires a CAS internally. Under high call rates this can become hot.
4. Avoid time.After in Process. It allocates a timer per call. Use time.NewTimer and Reset:

type worker struct {
    timer *time.Timer
}

func newWorker() *worker {
    t := time.NewTimer(0)
    if !t.Stop() {
        <-t.C
    }
    return &worker{timer: t}
}

func (w *worker) Process(p any) any {
    w.timer.Reset(50 * time.Millisecond)
    defer w.timer.Stop()
    select {
    case <-someChan:
    case <-w.timer.C:
    }
    return nil
}

1. Pin the GC if needed. For deterministic-latency workloads, consider debug.SetGCPercent(-1) and explicit runtime.GC() between batches. This is advanced and only sometimes appropriate.

2. Avoid interface{} heap escapes. When passing a payload through Process, the compiler may heap-allocate it. For very hot paths, batch payloads to amortise.

Best Practices¶

• One pool per workload, sized for the workload's bottleneck.
• Workers own their state; methods touch only their own fields.
• Interrupt is meaningful for any long-running Process. Implement it.
• Terminate is the place to release expensive resources. Implement it.
• Use ProcessCtx in HTTP handlers — propagate the request context.
• Use ProcessTimed for batch jobs with hard SLAs.
• Wrap the pool in a typed module-internal type. Hide interface{}.
• Test under realistic concurrency. A pool that handles 4 concurrent callers is not the same as a pool handling 4000.

Edge Cases and Pitfalls¶

Interrupt runs concurrently with Process¶

Common mistake: assuming Interrupt runs after Process. It does not — it runs during. Any field touched by both must be synchronised.

Terminate does not run if you do not call Close¶

If your program exits without calling Close, Terminate is never invoked. Resources held by workers will not be released. The OS will clean up file descriptors, but any external state (database transactions, lock files) may be left in a bad state.

Always defer pool.Close().

Factory panics fail-fast¶

If the factory passed to tunny.New panics during n calls, the panic propagates and the pool is not constructed. Any workers that were already built are leaked goroutines until their factories also fail or you call Close. Actually — they were not yet started; tunny.New constructs lazily in the standard implementation. Check the source for your version. Either way: do not panic in the factory unless that crash is acceptable at startup.

BlockUntilReady blocks the pool's dispatch loop¶

If BlockUntilReady takes a long time, the worker is effectively unavailable. Other workers can still serve, but this one is paused. That is the intended behaviour — but be aware: a deadlock in BlockUntilReady deadlocks one worker permanently. The pool can survive losing one worker; it cannot survive losing all of them.

ProcessTimed's timeout is total, not per-phase¶

If the queue is full and your timeout is short, you may time out before reaching a worker. From the caller's view this is fine. From the operations view, you might expect "the worker is just slow", but the worker has not even started.

A monitoring practice: separately count queue-time and work-time. We will see this in professional.md.

ProcessCtx versus Process semantic differences¶

• Process returns any.
• ProcessCtx returns (any, error).

If you wrap them generically:

func (p *MyPool) Process(in In) Out {
    return p.inner.Process(in).(Out)
}

func (p *MyPool) ProcessCtx(ctx context.Context, in In) (Out, error) {
    r, err := p.inner.ProcessCtx(ctx, in)
    if err != nil {
        var zero Out
        return zero, err
    }
    return r.(Out), nil
}

Note the zero-value handling on error. This is easy to forget.

Interrupt should be safe to call when Process is not running¶

Tunny may, in some edge cases, call Interrupt shortly after Process returned. Be defensive — check internal state before acting:

func (w *worker) Interrupt() {
    w.mu.Lock()
    defer w.mu.Unlock()
    if w.cancel == nil {
        return // not running, nothing to do
    }
    w.cancel()
}

Worker panics propagate to the goroutine¶

If Process panics, the panic happens in the worker goroutine. The pool does not catch it. The program crashes. Recover inside Process if you cannot trust the work:

func (w *worker) Process(p any) (out any) {
    defer func() {
        if r := recover(); r != nil {
            out = fmt.Errorf("panic: %v", r)
        }
    }()
    return riskyWork(p)
}

There is some subtlety about whether the worker is then usable for more calls. In modern tunny, yes — the wrapper function is built so a recovered panic does not kill the worker goroutine. In older versions, the worker goroutine could die. Always run defer recover to be safe regardless of version.

Common Mistakes¶

Mistake 1 — forgetting to implement all four methods¶

If your worker type does not implement BlockUntilReady, the program does not compile. (Good.) But it is easy to type the name wrong (BlockUntilReady vs BlockReady) and end up with an implicit cast error. Pin down the method names; copy-paste them from the docs.

Mistake 2 — sharing mutable state across worker instances¶

shared := make([]byte, 1024)
pool := tunny.New(4, func() tunny.Worker {
    return &worker{buf: shared}
})

All four workers share the same byte slice. When they all Process at once, races ensue. Make the slice per-worker:

pool := tunny.New(4, func() tunny.Worker {
    return &worker{buf: make([]byte, 1024)}
})

Mistake 3 — using Process then ProcessCtx interchangeably¶

Process returns any. ProcessCtx returns (any, error). Mixing them up leads to runtime panics:

r := pool.ProcessCtx(ctx, x).(MyResult) // does not compile — 2 return values

Either always use Process (no cancellation) or wrap so the caller never sees the difference.

Mistake 4 — using BlockUntilReady for per-call delays¶

BlockUntilReady is invoked before every call, but its semantic intent is "I am ready/not ready as a worker." If you put time.Sleep(100ms) in there to simulate rate limiting, the pool throughput drops to one call per worker per 100 ms — which may be what you want, but more likely you wanted a shared limiter as in the example earlier.

Mistake 5 — forgetting to make cancel() no-op when not running¶

A worker that calls cancel() on a nil CancelFunc panics. Always check:

if w.cancel != nil {
    w.cancel()
}

Mistake 6 — calling Close while Process is in flight¶

If your Close runs before all in-flight Process calls have returned, those in-flight calls may panic on send-on-closed-channel. Always coordinate: complete all Process calls before Close.

The sync.WaitGroup pattern in the junior examples is the standard answer.

Common Misconceptions¶

"tunny.New is harder than NewFunc"¶

It is a bit more code. But the moment you need per-worker state, tunny.New is easier — the alternative (closures-over-globals or sync.Pool inside NewFunc) is messier.

"Interrupt cancels Process synchronously"¶

It does not. Interrupt sends a signal. Process keeps running until it observes the signal and returns. The caller's wait, however, has already ended — they got the timeout error.

"ProcessCtx and ProcessTimed are the same"¶

ProcessCtx propagates all cancellation reasons. ProcessTimed only propagates timeout. ProcessCtx is the strictly more general API. Prefer it.

"Workers run forever"¶

Workers run until the pool is closed. They are not immortal across pools — different *tunny.Pool instances have different workers.

"NewCallback is for fire-and-forget"¶

It is not — it is still synchronous. You can call pool.Process(func(){ ... }), but Process still blocks until the callback returns.

Tricky Points¶

BlockUntilReady interacts with ProcessTimed in a non-obvious way¶

If a worker is blocked in BlockUntilReady and the caller's ProcessTimed deadline elapses, the worker is still blocked in BlockUntilReady. The caller gets ErrJobTimedOut. The worker does not receive an Interrupt because it has not yet started Process. So a long BlockUntilReady can effectively make a worker useless even though it is alive.

Best practice: keep BlockUntilReady reactive (poll a flag) so deadlines can still bail it out. Or use a context-aware wait:

func (w *worker) BlockUntilReady() {
    _ = w.lim.Wait(context.Background()) // does not respect deadlines from callers
}

A more deadline-aware version requires plumbing the caller's context into the worker, which tunny does not give you directly. You may need to use the payload as a carrier:

type Job struct {
    Ctx     context.Context
    Payload string
}

…and check ctx.Done() inside Process. The Worker interface itself does not connect the caller's context to BlockUntilReady.

Worker reuse means worker state can carry over¶

If your worker has a bytes.Buffer field, it carries content from one call to the next unless you reset it. Common bug:

func (w *worker) Process(p any) any {
    // forgot w.buf.Reset()
    w.buf.WriteString(p.(string))
    return w.buf.String()
}

After 3 calls, you have appended three strings. Always reset.

The factory is called sequentially, not in parallel¶

If your factory is slow (loads a 1 GB model), constructing a pool of 16 workers takes 16 * factory_time. Tunny does not parallelise factory calls. If you need parallel construction, do it yourself:

workers := make([]tunny.Worker, 16)
var wg sync.WaitGroup
for i := range workers {
    i := i
    wg.Add(1)
    go func() {
        defer wg.Done()
        workers[i] = newExpensiveWorker()
    }()
}
wg.Wait()
i := 0
pool := tunny.New(16, func() tunny.Worker {
    w := workers[i]
    i++
    return w
})

This is a workaround. Use it when factory time is genuinely expensive.

Test Yourself¶

1. Define a Worker for a SHA-256 hasher with a reusable hash.Hash instance.
2. Implement Interrupt for a worker whose Process does a 10-second time.Sleep.
3. Write a ProcessCtx call that respects an HTTP request's context.
4. Explain when BlockUntilReady is called and when it is not.
5. Explain the difference between ProcessTimed's timeout and BlockUntilReady's wait.
6. Implement a worker that holds a *sql.Conn and releases it in Terminate.
7. Write a typed wrapper Pool[In, Out] over tunny.New.
8. Implement a worker that recovers from panics in Process and reports them as a result error.
9. Why is Interrupt called from a different goroutine than Process?
10. When is NewCallback the right choice?

Tricky Questions¶

Q1. Your worker's BlockUntilReady does time.Sleep(100 * time.Millisecond) on every call. The pool has 8 workers. What is the maximum throughput?

A1. 80 calls per second. Each worker can serve 10 calls per second (1 / 100 ms). With 8 workers, 80. The Process time is on top of this — if Process takes 50 ms, the actual throughput is 1 / (100 + 50) ms per worker = ~6.67 per worker per second, ~53 per second total.

Q2. A worker's Process is mid-call. You call Pool.Close(). What happens?

A2. Close waits for the in-flight Process to finish. Then it calls Terminate on each worker. Then it returns. While waiting, calls to Process on the closed pool panic.

Q3. A worker holds a *sql.Tx. It crashes in the middle of Process due to a panic. What is the state of the database?

A3. Depends on driver and what was happening. The transaction is likely abandoned and will be rolled back when the connection times out or returns to the pool. To be safe, wrap Process in a defer recover() that explicitly rolls back the transaction.

Q4. ProcessCtx is called with a ctx that has already been cancelled. What happens?

A4. ProcessCtx returns (nil, ctx.Err()) essentially immediately. The worker may or may not be invoked depending on race conditions in the queue. Best practice: do not pass already-cancelled contexts.

Q5. Your Interrupt does nothing. What is the user-visible effect of ProcessTimed?

A5. From the caller's view, ProcessTimed correctly returns ErrJobTimedOut after the deadline. From the worker's view, Process keeps running until it finishes naturally. The result is discarded. The worker is unavailable to other callers until Process returns. So timeouts work, but slowly — and your effective pool size drops while timed-out workers are still running.

Q6. What happens if two Interrupt calls land while one Process is running?

A6. Both calls invoke your Interrupt method. If your method is idempotent (closing an already-closed cancel context is safe), no problem. If not (e.g. close(ch) on an already-closed channel), you panic. Make it idempotent.

Q7. Why does BlockUntilReady exist? Couldn't I just block at the start of Process?

A7. Yes, you could — but then the worker has been "assigned" to a payload while still waiting. That means the caller has been queued onto this worker; if other workers free up, they cannot pick up that caller. With BlockUntilReady, the worker is not assigned until ready, so the dispatcher can route to whichever worker is actually free first.

Q8. How does the pool decide which worker handles a given Process call?

A8. Whichever worker is currently in BlockUntilReady and just returned, basically. The dispatch is a channel send to whichever worker is reading. It is essentially "first available worker wins". You cannot prefer one worker over another.

Q9. Can I have heterogeneous workers in one pool?

A9. Technically yes — your factory could return different concrete types satisfying Worker. But the dispatch is round-robin-ish — there is no way to route a payload to a specific worker type. So heterogeneous workers in one pool only make sense if all of them can handle every payload.

Q10. Why does Process not take a context.Context directly?

A10. Because Process is part of an interface designed before contexts were idiomatic. ProcessCtx is the bolt-on. Inside the worker, you can plumb the payload to carry the context. Tunny does not give you the caller's context for free, but you can simulate it.

Cheat Sheet¶

Constructors:

  NewFunc(n, fn func(any) any)             - simple stateless
  New(n, factory func() Worker)            - full Worker interface
  NewCallback(n)                           - payload is a func()

Worker interface:

  Process(any) any         - do the work
  BlockUntilReady()        - wait until ready (rate limit, GPU)
  Interrupt()              - cancellation signal from pool
  Terminate()              - resource cleanup on Close

Calling:

  Process(payload)                                - blocking, no cancel
  ProcessTimed(payload, d)        -> (result, err) - timeout
  ProcessCtx(ctx, payload)        -> (result, err) - context-aware

Errors:

  ErrJobTimedOut       - ProcessTimed deadline elapsed
  ErrPoolNotRunning    - pool was closed
  ctx.Err()            - ProcessCtx context fired

Lifecycle:

  factory() -> worker
                |
                v
  Idle -> BlockUntilReady -> Process -> Idle (repeat)
                |
                v
              Close
                |
                v
          Terminate()

Self-Assessment Checklist¶

• Can implement a stateful Worker with a per-worker buffer.
• Can implement Interrupt with three different mechanisms.
• Can decide between NewFunc, New, and NewCallback.
• Can use ProcessTimed and explain its two phases.
• Can use ProcessCtx in an HTTP handler with r.Context().
• Can write a BlockUntilReady that integrates with rate.Limiter.
• Can write a typed wrapper that exposes only In/Out.
• Can recover from worker panics so they do not crash the process.
• Know when a long BlockUntilReady becomes problematic.
• Can explain why Interrupt runs concurrently with Process.

Summary¶

• The Worker interface promotes a worker from a function to an object with lifecycle hooks.
• tunny.New is the constructor for stateful workers; NewFunc is shorthand for stateless ones; NewCallback is a convenience for free-form closures.
• ProcessTimed adds a per-call timeout; ProcessCtx adds a per-call context.Context.
• BlockUntilReady, Interrupt, and Terminate are the three lifecycle hooks that turn the worker into a first-class concurrent object.
• Per-worker state is the killer feature: buffers, connections, models, decoders — all reused.
• Cancellation requires cooperation from your Interrupt implementation. Plumb it through.
• Hide the interface{} plumbing behind a typed wrapper.

What You Can Build Now¶

• A production-grade image processing service with per-worker decode buffers.
• A rate-limited API client with a shared rate.Limiter and BlockUntilReady.
• A CPU-bound HTTP service that respects request cancellation via ProcessCtx.
• A batch processor with hard SLAs using ProcessTimed.
• A typed pool wrapper module suitable for sharing across a company.

Further Reading¶

• The tunny repository's example folder.
• The golang.org/x/time/rate package — pairs naturally with BlockUntilReady.
• The context package — WithCancel, WithDeadline, WithValue.
• Various blog posts on the "Worker interface vs closure-on-submit" debate.

Related Topics¶

• Junior tunny (junior.md) — the NewFunc foundation.
• Senior tunny (senior.md) — internals of the workerWrapper.
• Channels (../../02-channels/) — what Interrupt essentially uses.
• context package (../../../05-context/) — required for ProcessCtx.
• sync.Pool (../../03-sync-package/) — composable with tunny.
• rate.Limiter (../../../09-rate-limiting/) — composable with BlockUntilReady.