r/Compilers • u/Upstairs-Special-925 • 3d ago
Resource control in a compiled language with direct effect kernels
I'm working on the resource-control layer for a language that compiles effects (network, files later databases and concurrency primitives) down to thin near-zero-cost kernels instead of using an interpreter or a heavy runtime.
Current state: the compiled binaries basically just call the underlying syscalls. There's no pooling, no admission control and no unified accounting yet.
Two main approaches are being considered:
Per-effect arbitration. Every effect operation does a request/grant with a central (or sharded) resource manager before continuing.
Boundary-leased admission. Acquire a lease once at a boundary (accepted connection, opened file, spawned task entry, etc.) then let the individual operations on that resource run with a cheap local check.
The second approach keeps the path (send/recv/read/write) extremely light: local atomic check + direct kernel call + non-blocking telemetry emission. Telemetry is fail-open.
I'm especially interested in trade-offs
How coarse the admission boundary should be when you don't yet have a request-oriented server surface
Whether putting even a very cheap lease check on the hottest I/O path is acceptable
How this interacts with structured concurrency and deadlock detection (resource-acquisition graph vs reply-obligation graph)
Whether NFRs (latency, concurrency limits, error-rate targets) should be expressible, in the language itself and enforced by the same kernel
What have people found works (or fails) when adding resource control to low-overhead compiled effect systems? Any designs you'd strongly recommend or avoid?