ParallelsealedPool machinery behind the parallel List combinators (parallelCollect: / parallelReduce:): a lazily-started pool of warm worker isolates, order- preserving chunk dispatch, and a one-flight-at-a-time gate. Programs normally call the combinators on List rather than this class directly (docs/internal/CONCURRENCY_ARCH.md §10).
Split a list into up to k contiguous chunks, in order.
Dynamic dispatch over the pool: one feeder task per worker pulls the next chunk off a shared cursor, ships job.value:chunk as a portable job, and files the result by chunk index — so a worker the OS parks on a slow-clocked cluster simply takes FEWER chunks instead of gating the wall (the straggler effect powermetrics pinned: spilled sibling-cluster threads run at ~1/3 frequency; profiling/worker-scaling/notes.md). Order-preserving.
One flight at a time: the pool lanes have no per-job addressing yet, so a second concurrent flight falls back to serial (correct, just not parallel). Cooperative scheduling makes check-then-set atomic between awaits.
Release the single parallel flight claimed by enter. The combinators call it on the success and failure paths alike, so the gate cannot stay wedged after an error.
Inputs below this run serially. Chosen from the measured crossover (profiling/parallel-combinators/): per-item work is unknowable, so this errs high — cheap blocks stay serial, and genuinely heavy small batches can use Worker.start: directly.
The warm pool: one worker per compute thread, capped at 4 — the measured sweet spot for interpreter-bound work on this class of machine (8 workers ran SLOWER than 4: P/E-core mix + memory bandwidth; profiling/parallel-combinators/notes.md). Started on first use; process exit ends them; a nil job stops one explicitly.