Section 51: Resource Limits and Execution Budgets¶

TECHSPEC-51 — Section 51 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

Programs can fail or become unsafe through excessive resource consumption even when their logic and types are otherwise valid.

The language and runtime must provide explicit resource controls.

2. Resource Categories¶

Relevant resources include: - Memory. - CPU time. - Execution steps. - Stack depth. - Task count. - File handles. - Network connections. - Open database transactions. - Buffer and collection sizes. - Compile-time evaluation resources. - Output volume.

3. Budget Declarations¶

A function, task, or runtime environment may declare resource budgets.

A budget must specify: - Resource being limited. - Limit and unit. - Scope. - Enforcement point. - Failure behavior. - Whether the budget is strict or advisory.

The final syntax remains open.

4. Runtime Enforcement¶

The runtime should enforce supported limits and produce explicit failures when they are exceeded.

A declared budget that the runtime cannot enforce must be reported as unenforced. It must not be represented as a guarantee.

5. Allocation Failure¶

Allocation may fail. The language must define how allocation failure is represented and propagated.

The runtime must not silently return invalid memory or corrupt program state.

6. Cancellation¶

Resource exhaustion may trigger cancellation.

Cancellation must be cooperative or enforced according to a defined runtime mechanism. Cleanup behavior and partially completed external effects must remain observable.

7. Fairness and Scheduling¶

Task scheduling and fairness guarantees must be documented. The runtime must not promise that every task will make progress unless its scheduler and execution model support that guarantee.

8. Denial-of-Service Resistance¶

Untrusted input and code should be subject to limits on parsing, recursion, collection sizes, decompression, serialization, and other potentially expensive operations.

Limits must be configurable without allowing untrusted code to raise its own limits.

9. Reporting¶

Execution records should identify: - Configured budgets. - Enforced budgets. - Peak or observed usage where available. - Limit violations. - Cancellation and cleanup outcomes. - Measurements that were unavailable.

10. Design Goal¶

Resource use must be bounded where required and observable where measured. A resource limit is a guarantee only when the runtime actually enforces it.

Source file: TECHSPEC-51.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.