The synthetic runner
Table of Contents
1. Summary
The synthetic runner, in ores.marketdata.synthetic, owns every running
generator. The demand set starts and stops generators. A person never starts a
feed for a party. The runner runs one tick thread for each generator and one
status thread. One class serves every asset class, because every generator
enters through the generator interface.
2. Detail
2.1. Demand starts a generator
When the service sends a demand set, the runner finds the generators whose universe covers the ids. It starts the ones that are not running and stops the ones whose ids left the set. A generator for an instrument that nobody demands does not run.
2.2. One owner
The map of running generators is keyed by generator id. Two generators that cover one vendor instrument conflict, because both would publish values for one id. The runner refuses the second and names the holder, so an author can fix it. The check compares the vendor instruments and not the internal series, because the adapter knows only vendor ids.
2.3. Start results
A start reports started, already_running or id_conflict. A feed whose
calibration policy refuses to start it without a fixing is skipped with the
reason.
2.4. Three facts the code shape does not show
- A generator that fails keeps the adapter running. The demand reply rejects its ids with a reason.
- A stop is asynchronous. The generator finishes its current tick.
- Restarting the adapter loses no stored state. The service sends the demand set again. See The identity an adapter runs as.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- The generator factory and the kind seam — completes: how the runner builds a generator.
- Demand drives what an adapter publishes — completes: what starts the generators.
- The simulator is one adapter plus the tools that author its generators — completes: the component the runner belongs to.