threadpool

nimony/lib/std/threadpool.nim

const StripeSize: int64
Tasks per stripe; must be a power of 2.
const BulkSize: int64
Max tasks drained per bulk dequeue.
const StageSize: int64
Tasks held in a worker's private staging ring; must be a power of 2.
```
type Task = object
  con: Continuation
```
proc toTask(c: Continuation): Task
proc poolPollIo(timeoutMs: int64): bool
Polls one I/O backend once; returns true if it delivered anything. std/ioring registers one of these.

type WorkerMetrics = object
  enqueueMiss: uint64
  dequeueMiss: uint64
  tasksSubmited: uint64
  tasksHandled: uint64
  tasksStealed: uint64

var workerMetrics: seq
var workerCount: int64
var gReactor: proc (timeoutMs: int64): bool {.nimcall.}
var gReactorState: int64
0 until gReactor/gReactorWaits — and everything they reach — are fully set up. It has to be PUBLISHED rather than merely assigned: initPool starts the workers, and only then does ioring.setupRing allocate the per-lane arenas the reactor indexes and finally point gReactor at itself. Nothing orders those plain stores against each other, so on a weakly ordered machine a worker could see the new reactor and an arena seq that is still empty. reactorReady pairs an acquire with setupRing's release.
var gReactorWaits: bool
Does gReactor(ms) actually sleep for up to ms? Set from the I/O backend (see BackendRelays.waits). While it is false an idle worker has to do the sleeping itself, because a reactor that only peeks would otherwise leave the loop spinning on a core.
var threadIdx: int64
proc submit(t: Task; h: int64)
Submit a task to the pool. Non-lossy with "caller-runs" backpressure: try the hinted stripe, then the others (absorbing bursts); if every stripe is full, run the continuation inline — trampolining it on the calling thread and handing the remainder back to the pool the moment a slot frees — rather than dropping it or blocking.
Why caller-runs and not a blocking wait: workers re-submit continuations from inside the trampoline (see workerLoop). A blocking submit could park every worker on a full queue with none left to drain it -> deadlock. Caller-runs instead guarantees forward progress (a producer that outruns the pool simply does the work), so the queue stays bounded at StripeCount*StripeSize and no submitter ever stalls.
proc submit(c: Continuation; hint: int64)
Convenience: submit a bare continuation as a task. On a worker with the default hint, the task is first staged on the private lock-free ring and handed to the shared stripes in bulk on the next worker cycle (see flushStaged); everything else enqueues immediately.
proc poolHelp(): bool
proc reactorReady(): bool
Has the I/O ring published its reactor? See gReactorState.
proc reactorPoll(timeoutMs: int64): bool
Drive the I/O reactor if there is one, and the do-nothing default until there is. Every caller of gReactor goes through this.
proc initPool()
proc isPoolWorker(): bool
True on a thread created by initPool. threadIdx is only meaningful as an identity on those: it is a threadvar defaulting to 0, so every foreign thread (the main thread included) reports 0 — the same value worker 0 uses. Anything that indexes per-thread state by threadIdx must ask this first.
proc stopped(): bool
proc shutdownPool()