jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Preserve periodic trigger-kind writer census

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-21 18:52:31 -07:00
commit 1387d4e722
2 changed files with 52 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

26
artifacts/exports/rt3-1.06/runtime-effect-kind8-late-bringup-note.md
View file

@ -99,6 +99,32 @@ The ordinary reload strip is bounded in the same negative way now:
So the remaining late-bringup/control-lane frontier stays between reload and service rather than
inside the already-bounded restore loop itself.
## Current Writer Census
The direct writer set for `[event+0x7ef]` is narrower now too:
- `0x0042d5a0`
- zero-initializes the live runtime-effect record control band
- clears `[event+0x7ee]`, `[event+0x7ef]`, `[event+0x7f4]`, `[event+0x81f]`, `[event+0x823]`,
and `[event+0x82b]`
- `0x0042e11a`
- straight copy helper over the same control band
- copies `[event+0x7ee/+0x7ef/+0x7f0/+0x7f4...]` from one live row into another
- `0x00430b50`
- the already-grounded follow-on runtime-effect builder
- reaches the fresh live row through `0x00432ea0 -> 0x0042d5a0`
- then seeds `[event+0x7ef]` to `2` or `3` from the current `[world+0x11]` threshold
- also sets `[event+0x7f5] = 1`
- `0x00443526` and `0x00443601`
- the already-grounded late retags to `5` and `2`
So the active periodic-company/control-lane question narrows again:
- ordinary reload `0x00433130 -> 0x0042db20` does not itself pass a trigger kind
- the late service strip gates strictly on `[event+0x7ef]`
- and the currently grounded nonzero seed outside the scenario-name retags is the follow-on
builder reached from the service/dispatch family rather than from the reload loop itself
## Post-Load Scenario Fixup
- `shell_apply_scenario_name_specific_post_load_world_and_object_fixups` `0x00442c30`

26
docs/rehost-queue/periodic-company-control-lane-2026-04-21.md
View file

@ -152,3 +152,29 @@ The ordinary reload path is narrower in the same negative way now too:
So the remaining periodic-company question stays between reload and service: the checked restore
path repopulates the rows, but the later trigger-kind gate lives only in the service strip.
## Current Writer Census
The direct writer set for `[event+0x7ef]` is narrower now too:
- `0x0042d5a0`
- zero-initializes the live runtime-effect record control band
- clears `[event+0x7ee]`, `[event+0x7ef]`, `[event+0x7f4]`, `[event+0x81f]`, `[event+0x823]`,
and `[event+0x82b]`
- `0x0042e11a`
- straight copy helper over the same control band
- copies `[event+0x7ee/+0x7ef/+0x7f0/+0x7f4...]` from one live row into another
- `0x00430b50`
- the already-grounded follow-on runtime-effect builder
- reaches the fresh live row through `0x00432ea0 -> 0x0042d5a0`
- then seeds `[event+0x7ef]` to `2` or `3` from the current `[world+0x11]` threshold
- also sets `[event+0x7f5] = 1`
- `0x00443526` and `0x00443601`
- the already-grounded late retags to `5` and `2`
So the remaining control-lane question is narrower again:
- ordinary reload `0x00433130 -> 0x0042db20` does not itself pass a trigger kind
- the late service strip gates strictly on `[event+0x7ef]`
- and the currently grounded nonzero seed outside the scenario-name retags is the follow-on
builder reached from the service/dispatch family rather than from the reload loop itself