Table of Contents

Typhon runtime

In one line: the host that drives your systems — it owns the worker pool and the tick loop, turning a DatabaseEngine into a running, self-ticking world.

TyphonRuntime.Create(dbe, schedule => …, options) takes your engine, a schedule of systems (tracks → DAGs → phases), and RuntimeOptions. Start() spins up the worker pool and the metronome; the world ticks itself until Shutdown(). You don't drive the loop — there is no "run one tick" call. You start it, then observe it (CurrentTickNumber, telemetry) and feed it (input queues) from the outside.

What happens inside each iteration — one Unit of Work, one transaction per system, the fence — belongs to the tick; the runtime just drives it.

The runtime is recommended but optional: request/response and batch apps drive the engine directly through transactions and never declare a system. Reach for it when you have continuous, parallel, tick-driven logic. Two lifecycle hooks cover the special moments — OnFirstTick (rebuild Transient state after a restart) and OnShutdown (a final Immediate-durable save before the process exits).

How it relates

  • Tick — the iteration the runtime drives; it owns the per-tick mechanics (UoW, per-system transaction, fence).
  • System — what you register on the schedule for the runtime to run.
  • Scheduler & phases — the schedule structure the runtime walks each tick.
  • DatabaseEngine — the runtime wraps one engine to make it tick.
  • Overload management — the runtime's standing policy when a tick runs over budget.
  • Spatial tiers & adaptive dispatch — how it scales dispatch across a large world without per-entity cost.

In the API

Learn & use

Edit this page