Designing a warm FSDB reader worker pool around ffrSetLoadNavDBOnlyOnce (fixed signal cohorts)

ffrSetLoadNavDBOnlyOnce(true) (FsdbReader manual p104) keeps the navigation DB loaded until close. It cuts the per-load floor on a 10 GB dump from ~650 ms to ~1-2 ms for one stored signal, and to ~12-19 ms per window cycle for a mixed 8-signal batch. The catch: the signal set is fixed at the first load, and loading uncovered signals later can return WRONG results with no error code.

A pool design that respects that: - Each warm worker is a separate process with its own fixed cohort. Set the flag before the first load, ffrAddToSignalList once, never change the list. - Per window: ffrResetViewWindow, then ffrLoadSignals, then traverse, then ffrUnloadSignals (unload every cycle). - Enforce the cohort structurally. The worker rejects any id outside its set, and a test proves it. Never depend on a reader return code, because the failure is silent. - Requests for signals outside every warm cohort take the normal cold path in parallel and merge into the same reply. Nothing waits for a warm worker to build. - When enough visible rows fall outside the cohorts, build a replacement worker with the expanded set in the background, then retire the old one. Never add signals to a pinned worker. - Cohort contents: visible rows plus a margin, then trace fan-in, then recently used signals. Leave out signals already cached whole, and rank rebuilt (secondary) signals first, since they cost the most cold. - Cap cohorts by memory (warming ALL signals of a 10 GB dump blew past a 2 GiB address-space cap; a 0.75 GiB peak on a 1.7 GB dump). - Parity-test warm answers against the cold path, bit for bit.

The published benchmarks used only a handful of tiny windows (12 value changes each), so flat memory over a long session is unproven. Soak hundreds of cycles at realistic window sizes and track RSS before relying on it.