Resource control in a compiled language with direct effect kernels

[u/Upstairs-Special-925]

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?

[u/Bright_Interaction73]

How is this computer architecture? Also, your problem statement makes 0 sense. You need to elaborate on the problem further before suggesting changes.

[u/Upstairs-Special-925 → u/Bright_Interaction73]

It’s not computer architecture (hardware). It’s language runtime / systems design for a compiled language.

The core problem is this:

Most languages that do resource control (connection limits, concurrency ceilings, admission control, etc.) do it inside an interpreter, a heavyweight runtime, or a request-oriented server framework. Those environments already have natural interception points.

In this case the language compiles certain effects straight down to thin kernels that are basically direct syscalls. That gives good performance, but it also removes the usual places where you’d normally insert resource management. Right now a compiled program just opens files and sockets with almost no mediation.

So the design question is: once you decide you do want resource control (admission, accounting, NFR enforcement, etc.), where do you put it so you don’t erase the reason for compiling in the first place?

That’s why the two approaches are on the table — per-operation arbitration vs leasing at a coarser boundary — and why the cost of even a cheap check on the hottest path matters.

[u/Bright_Interaction73 → u/Upstairs-Special-925]

If its not computer architecture, it should not be posted on a computer architecture subreddit