I had no idea what fuel is until this discussion.
What's the rationale? Just preventing infinite loops from hanging the host?
If the inefficiency is the counter, what if you just calculated an instruction offset - start < threshold every once in a while?
This probably makes no sense, ignore it, I'm way in over my head.
[1] https://github.com/bytecodealliance/wasmtime/issues/4109
[2] https://github.com/bytecodealliance/wasmtime/blob/main/examp...
I first encountered this with gas in the Ethereum VM. For Ethereum, they price different operations to reflect their real world cost: storing something forever on the blockchain is expensive whereas multiplying numbers is cheap
I’m not sure what it’s used for in this context or how instructions are weighted
Let's consider that you create a serverless platform which runs wasm/wasi code. The code can do an infinite loop and suck resources while blocking the thread that runs the code in the host. Now, with a fuel mechanism the code yields after a certain amount of instructions, giving the control back to the host. The host can then do things such as stop the guest from running, or store the amount of fuel to some database, bill the user and continue execution.
Yes, rational is to provide a pragmatic and efficient solution to infinite loops.
There is a variety of ways to implement fuel metering with varying trade-offs, e.g. performance, determinism and precision.
In this comment I roughly described how Wasmi implements its fuel metering: https://news.ycombinator.com/item?id=44229953
Wasmi's design focuses on performance and determinism but isn't as precise since instructions are always considered as group.