401. Scheduling rules

When you call Run(), F-Mesh executes your components until processing finishes or a configured limit is hit. This page describes that behavior from a user perspective. To see what happened after a run (RuntimeInfo, per-cycle results), see Inspecting a run.

What happens when you call Run()

1. You build the mesh, connect pipes, and put initial signals on input ports.
2. You call Run() — a blocking call.
3. F-Mesh repeatedly activates every component that has signals on at least one input port. Ready components run concurrently.
4. After each wave, output signals are forwarded through pipes to downstream input ports.
5. Run() returns when a terminal state is reached. You then read results from output ports.

There is no background goroutine — the mesh is a computational graph you execute on demand.

When Run() stops

Reason	Error returned?
All signals processed (no component has input signals)	No — natural completion
CyclesLimit reached	Yes — ErrReachedMaxAllowedCycles
TimeLimit exceeded	Yes — ErrTimeLimitExceeded
Component error/panic with StopOnFirstErrorOrPanic	Yes — ErrHitAnErrorOrPanic
Panic with StopOnFirstPanic	Yes — ErrHitAPanic
Drain or hook failure	Yes

By default, F-Mesh applies a 1000 cycle limit and a 5 second time limit. Remove them for longer runs:

fm, err := fmesh.New("long-running",
    fmesh.WithUnlimitedCycles(),
    fmesh.WithUnlimitedTime(),
)

See Mesh configuration for all config options.

Error handling strategies

Control how the mesh reacts to component errors via ErrorHandlingStrategy:

Strategy	Behavior
StopOnFirstErrorOrPanic (default)	Stop on first error or panic
StopOnFirstPanic	Ignore errors; stop on panic
IgnoreAll	Continue regardless of errors and panics

fm, err := fmesh.New("durable",
    fmesh.WithErrorHandlingStrategy(fmesh.IgnoreAll),
)

When a component returns an error from its activation function, that error is reported through Run(). Whether the mesh stops depends on the strategy above. Signals already placed on output ports before the error are still forwarded.

For waiting-for-inputs behavior (synchronization across parallel chains), see Component — Waiting for inputs.

Hooks during execution

If you use hooks, mesh-level hooks fire around the whole run (BeforeRun, AfterRun) and around each wave of activations (BeforeCycle, AfterCycle). See Hooks.

Inspecting what happened

Run() returns (*RuntimeInfo, error). The error tells you why the mesh stopped; RuntimeInfo holds timing and per-cycle activation details — see Inspecting a run.

For most applications, checking the Run() error and reading output port signals is enough.