Skip to content

fix(concurrent): reject resizes that cannot reach the runner - #135

Merged
greenhat616 merged 2 commits into
perf/event-loop-03-benchfrom
perf/event-loop-04-resize-guard
Oct 21, 2026
Merged

greenhat616 merged 2 commits into
perf/event-loop-03-benchfrom
perf/event-loop-04-resize-guard

Conversation

@greenhat616

Copy link
Copy Markdown
Owner

Part 4/13 of the event-loop optimization stack · Bug fix. Stacked on part 3.

  • A test shows that splitting a connecting runner several times overflows its control channel and panics.
  • RunnerManager::resize_runner returns ResizeError instead of panicking when the channel is full or closed; the planner rolls back and the split is skipped.

…w its control channel

A runner that is still connecting does not read its control channel, yet
every split of it queues a `LimitTotal`. The ninth split overflows the
eight-slot channel and `resize_runner` panics.

Through the real strategy this needs a concurrency above 1024: each quick
start round splits connecting runners too, and the runner spawned by the
first round receives one limit per later round. The reachable bound is
kept as a passing test; the overflow cases are ignored until Phase C.
`RunnerManager::resize_runner` panicked when the runner's control channel
was full or closed. A connecting runner does not read its control channel,
so splitting it nine times overflowed the channel. The resize now returns
`ResizeError::Limit`, and the planner rolls back, so the split is skipped
and no runner is spawned for the second half.
@greenhat616
greenhat616 added this pull request to stack #145 October 16, 2026 02:38
@greenhat616
greenhat616 marked this pull request as ready for review October 21, 2026 05:32
@greenhat616
greenhat616 merged commit e75c5ce into dev Oct 21, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant