You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit cdd56d0
Browse filesBrowse the repository at this point in the historyBrowse files
Answer for the array a handle has itself written to
Review found three ways the write path could serve wrong data, and all
three are fixed here with a test apiece.
A handle reads api/info once when it opens the array, and `stamp` is
built from exactly the fields a write moves -- so a handle used to fill
an array kept its pre-fill stamp for good, and a Proxy given that handle
adopted a cache built while the chunks were still empty. A write marks
the metadata stale now, and whatever asks reads it again.
`serves_blocks` weighs whether splitting a chunk into blocks would pay,
which is nothing to do with whether the frame has an index worth
reading -- but the two shared one memoized source, so touching the block
path first (max_ranges is a public property, and Proxy reads it) cached
None and left written_chunks raising NotRanged ever after. The
judgement belongs at the call, not in the slot.
A complete array stamps `n<nonce>:<cbytes>` and a filling one whose
subscriber reports no mtime stamped the same string, which is the one
collision the whole design exists to prevent. Both carry a marker now.
Also from the review: invalidating the index no longer empties what
index_state hands a cache, nor drops layouts a written chunk can never
invalidate; _forget_index takes the lock a source is built under; the
run-length tag is read in the host's byte order rather than always
little-endian; and the fill bench built a C2Array per chunk rather than
per writer, which charged every timed write an untallied api/info. The
numbers move little -- 7.6x rather than 7.0x for eight writers over a
simulated WAN -- and the plan is corrected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments