feat(runtime): hold and release the workers for a debugger #722
No reviewers
Labels
No labels
loop
queue/failed
queue/queued
ready
status/parked
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
torbscript/language!722
Loading…
Reference in a new issue
No description provided.
Delete branch "loop/719-debug-worker-hold"
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?
Step 2b of #41, first half: the runtime side of the stop-the-world handshake for a debugger.
What changes
runtime/task.c:torb_debug_holdtakes the hold and returns once every other thread of the program is quiescent: parked at a statement (torb_debug_park), asleep in its scheduler, or inside a call that may block (torb_debug_quiet_begin/torb_debug_quiet_end).torb_debug_releaselets the parked threads go. A worker checks the hold at the top of its loop, so a sleeping worker that wakes parks before it runs anything. One load per loop while nobody holds.runtime/platform.c:torb_condition_broadcast.compiler/src/backend/bytecode/format.trb,runtime/machine.c: kernel operationsdebug.hold(91) anddebug.release(92), appended so nothing renumbers.runtime/tests/pool_test.c:the_hold_of_a_debugger_stops_every_other_worker_until_the_release. Two counting workers, a sleeping one, and a blocking call on the blocking pool; while held no counter moves and the returned blocking call runs nothing after it, and after the release all of them go on.Split
The planned second commit (
feat(vm): debug a program on more than one worker:workersFor, the park at a statement, the handshake in the VM,tests/debug/workersand the DEBUGGER.md update) is not in this PR. It needs a builttorbto produce the session's expected output. This PR therefore saysRefs #719, notCloses, so the merge leaves #719 open for that half.Refs #719
Review of
d42ab40(CI combined status: success; tier A, tier B, bootstrap, playground, cross-host C all green).the_hold_of_a_debugger_stops_every_other_worker_until_the_releasecovers counting workers, a sleeping worker and a returned blocking call (no counter moves while held, all continue after the release). No false-failure path: the "stands still" check only asserts no movement.torb_idle/torb_worker_loop: the holder storestorb_hold_onbefore it readssleepingunder the worker lock, and a waking worker clearssleepingunder that lock before it readstorb_hold_on, so it either still sleeps or parks. Blocking-pool workers are published (countstored aftertorb_worker_prepare) before they are enumerated; unprepared workers are handled. Second holder parks, takes the hold after the release; release only by the holder.RefsnotCloses, the split is stated. Nothing autonomous, no new ports, secrets or dependencies.format.trband dispatched inmachine.c.Non-blocking:
runtime/task.c:2544says the hold lock comes before a worker's lock "in the order at the top of the file", but that order comment (lines 41-44) does not name it. Add it there with the second commit.DebugHold/DebugReleaseare declared beforeDecimalLiteralinKernelOperationbut numbered afterMapSlot. Harmless (numbers are explicit), but a declaration at the end would match the list.