debugger: tasks as threads #41
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Tasks shown as DAP threads, and a worker pool the debugger can hold (section 14).
Source
Acceptance criteria
tests/debug/Dependencies
None known.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). Implements DEBUGGER.md section 20 / section 14 (tasks as DAP threads, pausing holds every worker); the design record is the specification, no collision with CONCEPT "Open Questions". Touches the debugger and the VM/runtime task pool (opus/high when implemented); likely overlaps the concurrency work, ordering settled in refine. next: refine (queued)
[loop:torbscript] refine: still queued behind the intake order. next: waiting (ready buffer full: #4, #163, #164, #223 are ready) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261023 until 2026-10-23T01:57:13Z
[loop:torbscript] decided by the loop: #41 is an epic of two steps, and step 1 is filed as #403. Why: the design record (DEBUGGER.md section 14) names two separate pieces of work. (1) Listing suspended tasks needs a read-only walk of the scheduler's queues, which the runtime does not offer (runtime/task.c has per-worker queues and a timer heap, no public enumeration), plus per-task stackTrace in compiler/src/debugger. (2) Holding a worker pool needs
workersFor(compiler/src/vm/interpret.trb) to give workers interpreters under the debugger and a stop-the-world handshake across threads; that changes the deterministic one-worker guarantee and has its own risks. Together that is more than one PR with one or two commits, and step 2 builds on the task identities of step 1, so splitting is the smaller and safer order. Step 1 first because it delivers 'each task is a thread' on the existing single-worker model and keeps the stop deterministic.Epic checklist:
Dependency/ordering: #39 and #40 (also debugger) are being implemented in parallel and touch the same files (
compiler/src/debugger/debuggee.trb,adapter.trb,tests/debug/, DEBUGGER.md section 20). Step 1 should start after they are merged or in review. Seed: neither step changes syntax, a std name looked up by string or a driver flag; a new debug native is internal.[loop:torbscript] refine: ready (as the epic of two steps). Goal, acceptance criteria, design record point (DEBUGGER.md sections 14 and 20), seed statement and size are in the decision comment above and in the step issue; the epic stays open until step 2 is filed and lands. Worker usage: ~85k tokens (sonnet). Releases claim refine by session:loop-torbscript-20261023. next: implement (step 1, after #39 and #40)
[loop:torbscript] refine: note: the
readylabel sits on #403 (step 1), not on this epic, so the implement stage does not pick up the whole epic. next: waiting (epic; step 1 is #403, step 2 is filed when it lands)[loop:torbscript] refine: step 1 (#403, PR #404) merged 2026-10-23; step 2 filed as #586 (worker pool the debugger can hold), one step issue at a time, next: waiting (epic; step 2 is #586)
[loop:torbscript] refine: re-checked 2026-10-29T17:30Z: step 1 (#403) landed, step 2 is #586 (intake done, in refinement). Nothing else to do on the epic.
next: waiting (epic; step 2 is #586)
[loop:torbscript] refine: re-checked 2026-10-29T19:56Z: step 2 (#586) has its implementation PR #603 open, CI pending. Nothing to do on the epic.
next: waiting (epic; step 2 is #586, PR #603)