[HalRiveria-Bot]

What was wrong: the dispatch loop slept 50 ms on every pass, even after a job had just finished, and only refilled the slot after the next sleep. That capped each slot at about 8 programs a second. The runspace loop's 100 ms sleep capped short workers at about 9 jobs a second per slot.

What changed:

• The dispatch loop goes straight round after a pass where a job finished. Otherwise it waits on the exit handles of programs still running, plus the cancel token, capped at 50 ms.
• It only waits on programs that haven't exited, so a -JobPollCompleted that keeps saying "not done" can't spin a core.
• The runspace loop waits on its workers' handles plus the token, capped at 100 ms.
• Above 62 running, both wait on the first 62 and notice the rest at the cap. WaitAny holds 63 handles at most on an STA thread.
• Dispatchers sharing a SemaphoreSlim still pause after a finished job. Without that, one with a queue kept every slot until it ran out and its sibling got none.

Behavior users can notice:

• Callbacks that run every pass (-PollCallback, -AbortPollCallback, -GroupReleaseCheck) can run many times more often when jobs finish quickly. The README now says to keep them cheap.
• A retry queued from -JobFinalize can start within milliseconds of the failure. The README says to cap retries and not count on the gap.

Measured (PowerShell 5.1 and 7, new harness section AB):

	Before	After
cmd /c exit 0, -MaxConcurrent 1 (5.1)	106 ms each	19 ms each
20 ms worker, -MaxParallel 1 (5.1)	102 ms each	23 ms each
80 short programs, two dispatchers sharing 1 slot (5.1)	7.8 s	5.1 s

Two dispatchers sharing one slot alternate as before (ABABAB).

Tested: the harness passes on 5.1 and 7 (300 assertions, none skipped). The two timing tests fail on main. The turn-taking test fails against the same change without the pause. New checks also cover a lagging -JobPollCompleted, 70 programs and 70 workers at once, a job whose .Proc isn't a process, and a batch inside a worker.

🤖 Generated with Claude Code