# Why Pliro limits a running program

[Programming guides](README.md)

A program can accidentally do far more work than you intended. Runtime limits help stop runaway work and report what went wrong.

## What is being counted?

An **instruction budget** limits the small execution steps Pliro performs; it is not simply a count of source lines. One line can require several steps. An **execution slice** is the work between cooperative checkpoints. A positive wait or completed input request allows another turn and starts a fresh instruction slice. **Cooperative cancellation** means the runtime checks for a Stop request at its checkpoints.

**Call depth** counts functions still waiting for other function calls to finish. If A calls B and B calls C, those calls are nested. This is different from calling one function many times in a loop after each previous call has finished.

The **event-work budget** counts event delivery and scheduled handler runs across the entire session. **Dispatch** means delivering an event; an **invocation** is one run of a handler. Waiting does not refill this budget. A **one-shot timer** becomes ready once, and **arming** it means starting its wait. **Bounded history** means the host keeps only a limited amount of past event information.

Runtimes enforce:

- a configurable instruction budget per cooperative execution slice;
- cooperative cancellation;
- a bounded user-function call-depth limit, configurable in session runtimes
  and fixed at 256 in the current generated native runtime;
- a session-wide event-work budget, 10,000 units by default, that charges every
  broadcast dispatch, matching key/pointer-press/pointer-release/completed-click dispatch, and
  queued handler
  invocation; a one-shot timer receives that single handler charge when armed,
  not a second charge when it wakes;
- bounded input size and event history in hosts that retain events.

A tight loop such as `while true:` without a positive wait or input request
eventually fails with the instruction-budget diagnostic instead of freezing the
[IDE](../concepts/ide.md) or browser.

The event-work budget is independent of instruction-budget slices and positive
waits never replenish it. Exceeding it fails with `E4018`.
Starting a persistent keyboard/pointer-event program without every required
host capability fails with `E4019` instead of silently finishing or waiting
forever. Calling `pointerX()` or `pointerY()` outside a pointer-event task
fails with `E4020`. Native targets that cannot provide the required host are
rejected earlier with `E6001`.

## Related entries

[Syntax and values](../syntax/README.md) · [Built-ins](../builtins/README.md) · [Programming guides](README.md)