Skip to content

adopt running_process::blake3_file for dev daemon-identity isolation #1285

Description

@zackees

Context

running-process now exposes a shared content-hash primitive for dev daemon-identity isolation (landed via zackees/running-process#891 / PR zackees/running-process#892):

// feature = "client"
pub fn running_process::blake3_file(path: &Path) -> std::io::Result<blake3::Hash>;

It hashes a file's bytes with blake3::Hasher::update_mmap_rayon — content-based (so same-version rebuilds get distinct identities), mmap + multi-core (page-cache-warm, ~1–3 ms for a 20 MB binary), and immune to the ASLR/IAT/.data mutation that makes the loaded image a per-run nonce.

The problem this fixes

soldr-daemon, FastLED/fbuild, and standalone zccache all obtain their daemon identity/discovery through running-process. In dev, two builds sharing one home root (e.g. ~/.soldr-dev) rendezvous on the same daemon pipe + pid file, so each sees the other as "stale-version" and displaces it on every invocation — a displace-stale war that wedges the compile daemon (NotRunning → thousands of uncached fallbacks). Full root-cause + evidence: zackees/soldr#2352.

The shims are already version-namespaced; the daemon identity is not.

Ask: adopt the primitive here

Dev builds only (official/release builds get no stamp → bare identity, single-daemon-on-upgrade prod semantics — only dev pays the cost):

stamp = "<version>-<first-16-hex of blake3_file(current_exe)>"   // e.g. 4.9.0-a1b2c3d4e5f6a7b8

Client/daemon agreement — propagate the VALUE, not the path:

  • Compute the stamp once at the top level and export it down the process tree, so every child + the spawned daemon inherits the value (one hash per build, not one per short-lived wrapper — a 200-crate build would otherwise re-hash ~200×).
  • Propagating the value (not the path) is also what makes it immune to the Windows self-update lock-rename dance: a running .exe is locked so updates rename it aside; the path is not a stable key but the already-computed hash value is.

Refs: zackees/soldr#2352 (design of record + evidence), zackees/soldr#2353 (interim soldr-side per-version fix to be swapped for this), zackees/running-process#891, zackees/running-process#892.

fbuild-specific

fbuild gets its daemon identity via zccache. Once zccache honors the inherited ZCCACHE_DAEMON_NAMESPACE stamp, fbuild inherits isolation for free — the work here is to ensure fbuild's dev invocations compute the stamp once at the top level (or inherit it from a parent soldr/zccache) and propagate the value down to every child and the spawned daemon, so co-located dev builds do not wage a displace-stale war on one pipe.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions