Module limits 

Lunatic-style per-process resource limits — the typed slot of caixa.lisp that wasm-engine consumes at component instantiation.

See theory/INSPIRATIONS.md §III.1 for the prior-art frame: every caixa Servico runs sandboxed by default; no “trust the author”.

(defcaixa
  :nome   "my-service"
  :versao "0.1.0"
  :kind   Servico
  :limits ((:memory     "64MiB")     ;; max linear memory per instance
           (:fuel       1000000)     ;; max wasm-instructions per request
           (:wall-clock "30s")       ;; max wall-clock per request
           (:cpu        "500m"))     ;; soft cgroup CPU share (millicores)
  :servicos ("servicos/my-service.computeunit.yaml"))

Authors omit the slot for “no limits” (today’s behavior). When set, wasm-engine M2 wires:

• LimitsSpec::memory → wasmtime::StoreLimits::memory_size
• LimitsSpec::fuel → Store::set_fuel + per-tick refill
• LimitsSpec::wall_clock → epoch deadline cancellation
• LimitsSpec::cpu → cgroup-v2 hint propagated via the pod spec

Structs

LimitsSpec

Per-process limits. All fields optional — None = unbounded for that axis.

Enums

LimitsError

Constants

LIMITS_CPU_MILLICORES_MAX

Upper-bound ceiling on the :limits :cpu axis, in Kubernetes millicores — every validated LimitsSpec::cpu past LimitsSpec::validate lies in 1..=LIMITS_CPU_MILLICORES_MAX (inclusive on both ends).

LIMITS_FUEL_MAX

Upper-bound ceiling on the :limits :fuel axis, in wasm instructions per outermost call — every validated LimitsSpec::fuel past LimitsSpec::validate lies in 1..=LIMITS_FUEL_MAX (inclusive on both ends).

LIMITS_MEMORY_WASM32_MAX_BYTES

Hard upper bound for :limits :memory, in bytes — the wasm32-wasip2 linear-memory ceiling. The canonical caixa Servico compilation target (theory/CAIXA-SDLC.md §V — Substrate / Nix) is wasm32-wasip2, whose linear memory is 32-bit- addressed at a 64 KiB page size; the in-spec maximum is 2^16 pages × 2^16 bytes/page = 2^32 bytes = 4 GiB exactly. A :limits :memory value above this bound is structurally unreachable under wasm32: wasmtime’s Store::limiter cannot grow past the 32-bit address space, so an authored "8GiB" either silently saturates at the engine’s effective cap or surfaces as a memory.grow trap at runtime, far from the source caixa.lisp.

LIMITS_MEMORY_WASM32_PAGE_BYTES

Structural floor for :limits :memory, in bytes — the wasm32-wasip2 linear-memory page size. The wasm spec defines linear memory in fixed 64 KiB pages (2^16 bytes); every typed memory cap is consumed by wasmtime::StoreLimits::memory_size as a per-component byte ceiling against which the engine checks every memory.grow request. A cap below one page (< 65536 bytes) is structurally a “no wasm linear memory allowed” cap — instantiation of any wasm component that declares (memory 1) (i.e. min=1 page, the canonical default for every cdylib-shaped wasm component cargo emits) fails immediately with memory minimum size of 1 pages exceeds memory limits; a min=0 component traps the first memory.grow(1) because the next-page allocation would cross the sub-page cap. Either way the typed value the wasm-engine consumes is operationally indistinguishable from LimitsError::MemoryZero (no memory at all), but the diagnostic surfaces at engine-load time rather than at caixa-build time, far from the source caixa.lisp.

LIMITS_WALL_CLOCK_MAX

Upper-bound ceiling on the :limits :wall-clock axis — every validated LimitsSpec::wall_clock past LimitsSpec::validate lies in 1ms..=LIMITS_WALL_CLOCK_MAX (inclusive on both ends, integer-millisecond magnitudes by the canonical-form gate immediately preceding).