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

Split acquisition replay consumers from rehydrators

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 22:36:08 -07:00
commit 8bec4d1c1b
2 changed files with 25 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/rehost-queue.md
View file

@ -108,10 +108,14 @@ Working rule:
position/scalar triplets, but current evidence still does not tie that replay family directly
to `[site+0x276]`
- the same replay strip is narrower than before now:
direct local inspection shows `0x0040ee10` only reading cached source lane `[site+0x3cc]`
in the checked range, while the bounded `0x00480710` neighborhood is working from
`[site+0x04]`, `[site+0x08]`, and `[site+0x3cc]` rather than `[site+0x276]` or the
cached tri-lane
direct local inspection now splits it more precisely:
`0x0040ee10` itself only reads cached source lane `[site+0x3cc]` in the checked range, and
the bounded `0x00480710` neighborhood is working from `[site+0x04]`, `[site+0x08]`, and
`[site+0x3cc]`; but the broader immediate continuation `0x0040e360..0x0040edf6` still
consumes `[site+0x2a8]`, `[site+0x2a4]`, and `[site+0x276]` around
`0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860`, so the replay family is
narrowed rather than ruled out for owner-company rehydration; in the checked range those
`[site+0x276]` uses are still reads/queries rather than a direct rehydrating store
- the second is narrower in the same way:
the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
`0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`