Runtime ownership and global lock

Documents the process-global runtime owner, mutex failure behavior, model and generation state, and the consequences of serializing every public operation.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
2 minutes

Documents the process-global runtime owner, mutex failure behavior, model and generation state, and the consequences of serializing every public operation.

Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.

Architecture topic: this page does not claim that the WordPress website implements or executes the described runtime behavior.

Observed owner

runtime/src/wasm_exports.rs stores one Mutex<Option<Runtime>>. The option distinguishes an uninitialized export surface from an initialized runtime; the mutex serializes every load, configuration, generation, reset, diagnostics, and release operation.

Owned state

Runtime owns the accepted model, KV cache, tokenizer, prompt and generated token vectors, last-result bytes, diagnostics bytes, sampling configuration, deterministic RNG, reusable forward scratch, and vocabulary logits.

Failure behavior

A poisoned or otherwise unavailable lock maps to error code 13, GenerationFailed. The current API has no concurrent request queue, session identifier, or multi-runtime handle. A future Worker or multi-model design must replace the singleton with explicit runtime instances or a command-owned service.

Invariant

At most one mutable operation may touch the runtime at a time. This is thread-safe serialization, not parallel inference.

Scope

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations

  • Identify the source, version, target environment, and owner.
  • Separate observed values from estimates and externally reported values.
  • Record trade-offs, unsupported cases, and fallback behavior.
  • Link performance statements to a compatible benchmark methodology.

Verification questions

  • What exact artifact, revision, backend, and environment were reviewed?
  • Which assumptions could change the result?
  • Which data should be retained so another engineer can reproduce the conclusion?