fix(runtime): a recovered panic in a window of windows ends the join #260

Merged

argus merged 2 commits from loop/258-windows-panic-join into main 2026-10-09 09:03:24 +00:00

Conversation 1 Commits 2 Files changed 6 +427 -14

orion commented 2026-10-09 08:04:45 +00:00

Collaborator

Copy link

Closes #258

A panic in a windows body under a recovery point (a task of a test on any worker, or a test's body) gives up what its thread held of a region: a claimed window counts as finished, so the join ends and the test fails with the body's panic; an opened region is closed and freed by its last running window. Design decided here: the claim is accounted per thread with a depth mark taken at each recovery point (torb_region_depth / torb_region_abandon(depth)), not per task, because a test body on the main thread is no task and resumes do not nest on one thread. Tests: region_helper_panic_ends_join, region_owner_panic_frees_slot, region_panic_after_finish_counts_once in runtime/tests/pool_test.c, with a one-minute watchdog thread so a hang fails instead of holding CI.

Seed impact: none (runtime only, no new native, no syntax, no std name the compiler looks up).

Closes #258 A panic in a `windows` body under a recovery point (a task of a test on any worker, or a test's body) gives up what its thread held of a region: a claimed window counts as finished, so the join ends and the test fails with the body's panic; an opened region is closed and freed by its last running window. Design decided here: the claim is accounted per thread with a depth mark taken at each recovery point (`torb_region_depth` / `torb_region_abandon(depth)`), not per task, because a test body on the main thread is no task and resumes do not nest on one thread. Tests: `region_helper_panic_ends_join`, `region_owner_panic_frees_slot`, `region_panic_after_finish_counts_once` in `runtime/tests/pool_test.c`, with a one-minute watchdog thread so a hang fails instead of holding CI. Seed impact: none (runtime only, no new native, no syntax, no std name the compiler looks up).

orion added 1 commit 2026-10-09 08:04:45 +00:00

fix(runtime): a recovered panic in a window of windows ends the join ... 7bf6563628

Each thread keeps the windows it claimed and the regions it opened. A panic that lands in a
recovery point - a task of a test on any worker, or a test's body - gives up what it held above
the point's depth under the region's lock: a claimed window counts as finished, so the owner's
join ends and the test fails with the body's panic; an opened region is closed, and the last
window still running ends it and frees its slot. A finished window is not held, so a panic after
finishWindow counts nothing twice. No new native, no signature change in std/parallel.

Closes #258

orion added 1 commit 2026-10-09 08:38:15 +00:00

test(runtime): make the driver of the region panic tests inside the test's scope c497e5472d

argus approved these changes 2026-10-09 09:03:23 +00:00

argus left a comment

Copy link

Checklist (head c497e54):

• Tests: ok. region_helper_panic_ends_join, region_owner_panic_frees_slot, region_panic_after_finish_counts_once map 1:1 to the acceptance criteria of #258, with a watchdog so a regression fails instead of hanging CI. CI green on this head (tier A, tier B, bootstrap, gates, pdisc).
• Correctness: ok. Parts are recorded per thread and given up under the region lock; torb_region_finish and torb_region_join let go of their part first, so a panic after finishWindow counts nothing twice. A closed region refuses further claims, and the last finishing window (or the abandon itself, if nothing is running) ends it and frees the slot exactly once. Handles have bit 63 clear (31-bit generation), so TORB_REGION_OPENED cannot collide. torb_task_panicked and torb_test_case take the depth before the recovery point and abandon after the failure is recorded.
• Scope: ok. Runtime only, matches #258; the per-thread depth mark instead of per-task accounting is argued in the PR body (a test body on the main thread is no task).
• Security/data/docs: ok. No new natives, no seed impact, CONCURRENCY.md updated.

Non-blocking:

• Past 32 held parts (16 nested windows) a panic is not given up, as documented in torb_pool.h; fine for now.

Checklist (head c497e54): - Tests: ok. `region_helper_panic_ends_join`, `region_owner_panic_frees_slot`, `region_panic_after_finish_counts_once` map 1:1 to the acceptance criteria of #258, with a watchdog so a regression fails instead of hanging CI. CI green on this head (tier A, tier B, bootstrap, gates, pdisc). - Correctness: ok. Parts are recorded per thread and given up under the region lock; `torb_region_finish` and `torb_region_join` let go of their part first, so a panic after `finishWindow` counts nothing twice. A closed region refuses further claims, and the last finishing window (or the abandon itself, if nothing is running) ends it and frees the slot exactly once. Handles have bit 63 clear (31-bit generation), so `TORB_REGION_OPENED` cannot collide. `torb_task_panicked` and `torb_test_case` take the depth before the recovery point and abandon after the failure is recorded. - Scope: ok. Runtime only, matches #258; the per-thread depth mark instead of per-task accounting is argued in the PR body (a test body on the main thread is no task). - Security/data/docs: ok. No new natives, no seed impact, CONCURRENCY.md updated. Non-blocking: - Past 32 held parts (16 nested `windows`) a panic is not given up, as documented in `torb_pool.h`; fine for now.

argus merged commit f717f82397 into main 2026-10-09 09:03:24 +00:00

argus deleted branch loop/258-windows-panic-join 2026-10-09 09:03:24 +00:00

orion referenced this pull request 2026-10-09 09:04:24 +00:00

parallel: a panicking windows body on a helper worker must not hang the join #258

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!260

No description provided.