Skip to main content

Module cache

Module cache 

Source
Expand description

The runtime cache segment: regenerable artifacts the running application writes for its own later launches, all of them in cache/0.

One file per writer role is the rule the layout is built on. The application writes this segment and nothing else, a build writes its own, so a build running against a live editor never touches the file the editor is writing. Within the segment an index keyed by producer and key separates the entries, which is what lets two adapters of one producer share a file, and the shader cache share it with the driver pipeline blobs.

Which files those are is not this module’s business: a host anchors the two it wants, having resolved them from its own state tree. Until one does, every operation here is a miss.

A lookup has a second tier behind it: the segment a bundle ships, which cn export warms so a player’s first launch does not pay the compile. A host resolves it against the content root rather than the writable one, so the two are one file except on an install that cannot write beside its data – which is the whole reason the tier exists.

The file is touched twice: once when the first lookup reads it, and once per flush. The bundled tier is read once and never written. Everything between is memory, so a producer that stores in a loop costs one write rather than one per entry. A crash before a flush costs the recompute of whatever had not been written, which is the same price deleting cache/ already carries.

Every operation is best-effort: a miss, an unreadable segment, or a failed write leaves the caller to produce the artifact the slow way. Two applications running against one checkout do share this file, and the later flush wins; what the loser had cached is recomputed on its next launch.

The container format is concinnity_core::blob, which is I/O-free; the file reads and writes live in segment.

Structs§

CacheAnchor
The two segment files a run consults, named by whatever anchored them.
Segment
A segment’s entries in memory, plus whether they differ from the file they were read from.

Enums§

CacheEntryKind
Which producer an entry belongs to.

Constants§

CACHE_BUDGET_BYTES
How much payload the segment may hold. Every shader edit orphans the artifact it replaces and neither driver pipeline blob evicts internally, so a long-lived checkout would otherwise accumulate forever. Generous next to the ~100 live entries one build needs; flush evicts down to it.

Functions§

anchor
Point the runtime cache at the files anchor names for the rest of the process, or until another anchor replaces it. Until a host calls this every operation above is a miss: artifacts are produced fresh rather than warmed from disk.
clear_anchor
Drop the anchor, leaving the process with no cache to warm from.
delete
Drop key’s entry, for a caller whose artifact turned out unusable.
flush
Write the segment to disk, if anything changed it since it was read, and report whether the file was written. Called when the work producing entries finishes – the end of a renderer init, a clean shutdown – never per entry.
load
The bytes kind stored under key, or None when there is no such entry (or nothing anchored a segment to look in).
load_bundled
The same lookup against the read-only segment a bundle ships, for a caller load missed. Read once like the writable one, so a run that consults it fifty times reads the file once.
store
Hold bytes under key until the next flush, reporting whether the segment took them: an entry already holding at least as many bytes is left alone, so a driver blob whose serialization only reshuffles does not make the flush rewrite the file.
verify_toolchain
Adopt id as the host shader toolchain the segment’s entries were produced by, discarding every entry when the segment names another one. Reports whether it discarded, which the caller logs.