Add configurable submit buffer
This commit is contained in:
21
README.md
21
README.md
@@ -17,11 +17,22 @@ if err := pool.Submit(func() { doWork() }); err != nil {
|
||||
|
||||
The pool creates the minimum workers immediately and grows on demand up to the
|
||||
maximum. A channel-driven scheduler owns worker lifecycle and a FIFO task queue
|
||||
with fixed capacity `maxWorkers/2`; once all workers and queue slots are
|
||||
occupied, `Submit` waits for room. With `maxWorkers == 1`, the queue has zero
|
||||
capacity and submissions wait for a worker. A successful `Submit` means the
|
||||
scheduler accepted the task; it does not mean the task has started or finished.
|
||||
`Close` stops new submissions and waits for accepted tasks to finish.
|
||||
with fixed capacity `maxWorkers/2`. Submissions first pass through a separate
|
||||
FIFO ingress buffer, whose default capacity is 128. Configure it with
|
||||
`WithSubmitBuffer`; zero keeps the ingress unbuffered, and negative capacities
|
||||
are rejected:
|
||||
|
||||
```go
|
||||
pool, err := worker.New(2, 8, worker.WithSubmitBuffer(1024))
|
||||
```
|
||||
|
||||
The ingress buffer and scheduler queue are separate capacity limits. When the
|
||||
ingress buffer is full, `Submit` waits until the scheduler can accept more work
|
||||
or the pool begins closing. With `maxWorkers == 1`, the scheduler queue has zero
|
||||
capacity, though the ingress buffer can still hold its configured number of
|
||||
tasks. A successful `Submit` means the pool accepted the task; it does not mean
|
||||
the task has started or finished. `Close` stops new submissions and waits for
|
||||
all accepted tasks, including buffered submissions, to finish.
|
||||
|
||||
After a task finishes, a worker exits immediately only when `total > min` and
|
||||
the number of *other* idle workers is greater than `min/2`. There is no idle
|
||||
|
||||
Reference in New Issue
Block a user