AI_Assistant/pcbjam
Watch
1
0
Fork
You've already forked pcbjam
 0
Code Issues Pull requests Projects Releases 4 Packages Wiki Activity Actions 2

Phase B: main-thread sleep parks its context; the real D blocker is DOM entries

Browse source 
wasm/shims/context_sleep.cpp: a main-thread nanosleep whose frame stands on a
scheduler context that OWNS the stack arms a mailbox wake and yield_parks that
context instead of suspending the stack in place. It lives in the sleep
primitive rather than in tool_manager.cpp on purpose - KiCad and the wx core
stay untouched (CLAUDE.md's fork rule) and the whole K7 class moves at once,
not just TOOL_MANAGER::RunSynchronousAction's spin loop.

MEASURED AT D-ON, and it is NOT what unblocks Phase D. The four canvas-tool
specs still fail, but the trace now names a different cause: the fatal swap is
old=<libcontext ROOT> new=<tool coroutine> with mouseEventHandlerFunc above it
- a DOM mouse handler entering wasm DIRECTLY on the main stack, bypassing the
tick. So one coroutine is entered two ways: by the tick through the dispatch
context as a STAR TRANSFER, and by DOM handlers as a DIRECT SYMMETRIC SWAP. A
capture written by one path cannot be rewound by the other -> index out of
bounds in doRewind. That is section 7 rule 5 (partial migration is worse than
none) in its purest measured form, and it is why the harness stays green: its
coroutines are only ever entered from one place.

So the next increment is the DOM event entries (mouse/key/wheel/resize must
hand their events to the dispatch context as the tick does), not another park
site. It subsumes the one-root work too: with no dispatch on the main stack,
resolve_root_identity() always answers "the running context".

Landing state: STAR_DISPATCH=0, kicad 139 passed / 1 (pre-existing occ-probe)
= baseline, with the sleep shim in and inert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LBjomQfKyRa3jBdeAKpmTw
This commit is contained in:
Gergő Törcsvári 2026-08-07 20:48:35 +02:00
commit 80468e7c5b
No known key found for this signature in database
GPG key ID: 8E75F2CDE64E5322
5 changed files with 183 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

49
docs/features/async/22-absorbing-libcontext.md
View file

@ -745,6 +745,55 @@ sleeping-in-place. Notes for whoever takes it:
never the harness battery — the harness has no `RunSynchronousAction` and will stay
green either way. That is this session's most transferable lesson.
### The sleep moved to a context — and the REAL blocker surfaced (2026-08-07)
**Built and measured.** `wasm/shims/context_sleep.cpp`: a main-thread `nanosleep`
whose frame stands on a scheduler context that OWNS the stack arms a mailbox wake and
`yield_park`s that context instead of suspending the stack in place; anything else
falls back to the Asyncify yield. It lives in the sleep primitive rather than in
`tool_manager.cpp` deliberately — KiCad and the wx core stay untouched (CLAUDE.md's
fork rule), and the whole K7 class moves at once instead of the one measured caller.
**One correction paid for on the way, worth keeping in mind for every future park
site: a context may have only ONE wake owner.** The first cut parked whatever context
was current, including the MAIN-LOOP context — whose wake already belongs to the rAF
pump. The frame wake then resumed a capture the sleep wake had consumed:
`doRewind` trap arriving through `wxWasmArmFrameWake`, and the eeschema simulator spec
went red at D-off. `wxWasmContextWakeIsPumpOwned()` now excludes the main-loop and
dispatch contexts (their parks are the pumps' contract); tool coroutines, which have
no other wake source, are exactly the ones that park. **D-off re-verified at 139/1
with the shim in — it is correct-or-inert exactly as required.**
**At D-on the four canvas-tool specs still fail, and the trace names a DIFFERENT
cause — the one that actually blocks Phase D.** The fatal swap is
`fcs old=<libcontext ROOT> new=<tool coroutine> rf=dynCall_iiii`, and the JS stack
above it is `mouseEventHandlerFunc` → `registerMouseEventCallback`: **a DOM mouse
handler entering wasm DIRECTLY on the main stack**, not through the tick.
So the same tool coroutine is entered by two different mechanisms:
| entry | path | how the coroutine is resumed |
|---|---|---|
| the tick (`wxWasmTopLevelTick`) | dispatch context → `fiber_transfer` | STAR: parked by the scheduler, capture owned by the scheduler swap |
| a DOM mouse/key handler | main stack, `current() == 0` → direct-swap fallback | SYMMETRIC: entered by `emscripten_fiber_swap` from the root |
A coroutine suspended by a star transfer and later resumed by a direct symmetric swap
rewinds through an entry path its capture was not written for — `index out of bounds`
in `doRewind`. This is doc 22 §7 rule 5 (partial migration is worse than none) in its
purest measured form, and it explains why the harness stays green: its coroutines are
only ever entered from one place.
**Therefore the next Phase B/D increment is not another park site — it is the DOM
event entries.** Every `registerMouseEventCallback` / key / wheel / resize handler that
today runs wx dispatch inline on the main stack must instead hand its event to the
dispatch context (enqueue + pump), exactly as the tick already does. Only when EVERY
entry into a tool coroutine goes through the scheduler does the mixed-mode rewind
class disappear. Note this also subsumes the "one root" work: with no dispatch on the
main stack, `resolve_root_identity()` always answers "the running context".
**Landing state: `wxWASM_STAR_DISPATCH` back to 0**, context-sleep and its
pump-ownership guard kept (inert at D-off, verified 139/1).
1. **pthreads.** Doc 21 §2 settled that every Asyncify park is main-thread and the lib
bridge's worker path is a blocking proxy. Phase A must re-check that libcontext is never
driven from a worker before assuming the scheduler is main-thread-only.