[tombl]

I think the closest existing concept to signals is the gas/fuel mechanism implemented in some WebAssembly runtimes, used by WASM blockchain VMs to preempt untrusted code. Runtimes either instrument the JITed code to check a fuel counter in every function/loop, or they register a timer signal/interrupt that periodically checks the counter.

From a similar handler, you could check if a signal flag has been set, then call a user-defined signal handler exported from the module.

If you don't control the runtime, you could do this instrumentation to the bytecode rather than the generated machine code, effectively simulating preemption via injected yield points.

[omginternets]

This sounds appealing. Can you point me to any resources (video, article, code, ...) that would help me evaluate this approach in more detail?

[tombl]

There don't seem to be many write-ups on this concept. The best reference seems to be existing implementations:

Wasmer's implementation of metering[0] just traps when it runs out of fuel. WasmEdge's implementation of interruptibility[1] checks a flag and stops execution if it's set.

While neither of these support resuming execution after the deadline, replacing the halt with a call to a signal dispatcher should work.

Wasmtime has two different implementations of interrupting execution that both support resuming[2]. The fuel mechanism[3] is deterministic but the epoch mechanism[4] is more performant. If you're free to pick your runtime, I'm sure you could configure Wasmtime into doing what you want.

[0]: https://github.com/wasmerio/wasmer/blob/master/lib/middlewar...

[1]: https://github.com/WasmEdge/WasmEdge/pull/910

[2]: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#...

[3]: https://github.com/bytecodealliance/wasmtime/pull/2611

[4]: https://github.com/bytecodealliance/wasmtime/pull/3699

[kazinator]

The idea of running code up to some resource limit and then aborting it is documented in the Lisp 1.5 manual from 1962, P. 34:

6.4 The Cons Counter and Errorset

The cons counter is a useful device for breaking out of program loops. it automatically causes a trap when a certain number of conses have been performed. The counter is turned on by executing count [n], where n is an integer. If n conses are performed before the counter is turned off, a trap will occur and an error diagnostic will be given.