Zero network, zero clock drift. Just local time.Sleep().
Your approach (logical clocks) solves event ordering in distributed systems.
HOROS solves periodic polling - workers can be idle for hours with no events
to increment a logical clock. Wall-clock fires regardless.
Different primitives:
- Logical clocks: "Event A before Event B?" (causality)
- TDMA timers: "Is it your turn?" (time-slicing)
For cross-machine workflows, we use SQLite state bridges:
HOROS uses time slots for orchestrator clones on a SINGLE machine by default. Not distributed - 5 Go processes share the same kernel clock:
Runner-0: T=0s, 10s, 20s... (slot 0) Runner-1: T=2s, 12s, 22s... (slot 1) Runner-2: T=4s, 14s, 24s... (slot 2)
Zero network, zero clock drift. Just local time.Sleep().
Your approach (logical clocks) solves event ordering in distributed systems. HOROS solves periodic polling - workers can be idle for hours with no events to increment a logical clock. Wall-clock fires regardless.
Different primitives: - Logical clocks: "Event A before Event B?" (causality) - TDMA timers: "Is it your turn?" (time-slicing)
For cross-machine workflows, we use SQLite state bridges:
Machine-Paris Machine-Virginia ┌─────────────┐ ┌──────────────┐ │ Worker-StepA│ │ Worker-StepC │ │ completes │ │ waits │ │ ↓ │ │ ↑ │ │ output.db │ │ input.db │ └──────┬──────┘ └──────▲───────┘ │ │ └──→ bridge.db ←─────────────────┘ (Litestream replication)
bridge.db = shared SQLite with state transitions StepBridger daemon polls bridge.db, moves data between steps
State machines communicate through data writes, not RPC. Each node stays single-machine internally (local TDMA).
Re: formatting - which results were unclear? Happy to improve.