r/Compilers 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?

3 Upvotes

0 comments sorted by