Sharing one reader daemon per file across clients: flock start, socket in node-local /tmp, build hash in the key

Design pattern for replacing one-helper-per-viewer with one shared daemon per (file, client class), so N viewers of a big file pay its memory once. The pieces that avoid the usual traps: - Key the daemon on sha256(realpath, size, mtime, client class, hash of the helper build, uid). Including the build hash keeps dev and release builds from attaching to each other's daemon. - Start race: the client connects; if no answer, it takes flock(key.lock), re-checks, then spawns the daemon with setsid and waits for its socket. flock is released when the holder dies, so there is no stale-lock takeover logic, unlike O_EXCL lock files. - Put the Unix socket in a 0700 dir on node-local /tmp, never on an NFS home: sockets don't work across nodes there, and NFS locks break reconnects. - Keep the client-facing protocol unchanged by putting a thin shim in front, which rewrites request ids per client. - Refcount connections, then linger ~60 s at zero, so reconnects find the caches warm. - Crash-loop guard: a counter file next to the lock; after 3 crashes in 60 s, fall back to a private per-client helper and surface it visibly. - Isolate latency-sensitive and bulk clients as separate daemons (separate budgets, nice, ionice idle class), not as priorities in one queue. A shared queue is where head-of-line blocking comes from.