Repository navigation
id: research: per-function gas metering, timeouts, and the multithreading question for user functions #5966
Description
Part of the worlds design program: #5955. Statements S40–S42 of the 2026-11-04 brief. Filed as dedicated research per Drew's rule for sub-parts that need their own documentation.
Questions (Drew, in substance)
- Per-function gas: "I don't know if there's a way to rate limit specific functions' gas usage, but that would be ideal." — Is there, in our Roc/wasm/host setup? Options to evaluate: fuel metering at the wasm layer, instruction counting, host-side accounting per capability call, cooperative yield points.
- Per-function timeout: the world code gives a function a certain amount of time; if it doesn't respond in that time, it closes. — What mechanism enforces this against a function that never yields (interruptible execution, epoch interruption, process isolation)?
- Multi-threading: "I know that there were discussions about how to do multi-threading, but I don't know if that ever was fully figured out." — Find those discussions (Roc community + our own repo history) and report the actual state: what was decided, what was left open, what it means for running many user functions per tick.
Scope notes
- The consumer is the per-user function mapping design (child of #5955): a world maps over N user functions per tick and must bound each one independently.
- Measure against the performance-tension design child too: metering overhead is the tax on the near-C-speed story — quantify it, don't hand-wave it.
- Check what the current host already enforces (world session/compile path in
pkgs/id/src/world_session/,pkgs/id/src/world_compile.rs) before proposing new machinery.
Done looks like
A research doc answering all three questions with evidence: mechanism options with measured or cited overheads, a recommendation for per-function gas + timeout, and the multithreading state-of-the-art summary.
Activity
developing-today commentedon Nov 5, 2026
CODE-1632
dezren39 commentedon Nov 5, 2026
Wave-2 tie-in — contradiction C4.
WORKING INTERPRETATION — shown to Drew in the main chat 2026-11-04 ~23:06 and not objected to; recorded here as an interpretation, not a ruling. The brief suggests timing out user functions by wall clock. The 2026-10-31 analysis records wall-clock deadlines as machine-dependent — acceptable host-locally (the journal syncs outcomes), but cross-host arena fairness requires fuel-style deterministic budgets, not wall-clock: an arena comparing user functions across hosts inherits non-determinism from wall-clock enforcement. Wall-clock stays acceptable for single-host / cooperative cases. This research should therefore evaluate per-function timeout mechanisms in two classes — deterministic (fuel) for cross-host contests, deadline-based for host-local execution — rather than treating "timeout" as one mechanism.
Record:
workspace/scratch/worlds-capabilities-brief-2026-11-04/conversation-tie-ins.md(C4, F10).dezren39 commentedon Nov 5, 2026
Wave-2 follow-ups filed from the prior-art research (Lane B). Granular sub-scopes of this issue, each carrying the relevant research findings + citations:
Research source:
workspace/scratch/worlds-capabilities-brief-2026-11-04/prior-art-research.md. Full wave-2 mapping:workspace/scratch/worlds-capabilities-brief-2026-11-04/wave2-map.md.dezren39 commentedon Nov 5, 2026
Ruling — C4 fuel budgets affirmed as a platform pillar (Drew, 2026-11-04 23:57 CST).
Per-function metering / fuel budgets — together with user-code handling (#5964) — are "very big parts of making this a platform that other people can build on top of, interact with, and reason about." Top importance.
Substance, as interpreted and now affirmed: cross-host fairness needs fuel-style budgets, not wall-clock timeouts (wall-clock is acceptable only single-host/cooperative per the original interpretation). The two-level metering adaptation (burst bucket + per-tick ceiling) is #6001.
Iteration doctrine (applies here in full): thorough research; test what we find; actively look for holes and gaps; expect to rework and rebuild multiple times to land the right solution. Early implementations may be locked to us in a test environment and need not be user-friendly at all — but everything built must retain the capability to become highly user-friendly later.
66 remaining items
developing-today commentedon Nov 9, 2026
🤖 Agent note · verified — parked (concurrent ownership / reconciliation pending)
doc(id): per-function gas, timeouts, and multithreading research (#5966)
doc(id): reconcile the two #5966 research passes into one record
Merge pull request #7874 from developing-today/queue/13814-5966-resea…