> However, piccolo works very hard to guarantee that piccolo::Executor::step returns in a bounded amount of time, even without the cooperation of the running Lua code.<p>The issue is that there exist ways to make a single bytecode instruction take an unbounded amount of time to execute. For example, Lua's "string.find()" is implemented in native code. The interpreter only sees a single OP_CALL opcode, so it will count it as 1 instruction executed. But the <i>actual</i> execution time of the native implementation of string.find() is dependent on its inputs, which are not only variable length strings, but can be maliciously crafted to run in exponential time. Here's an example, shamelessly stolen from Mike Pall himself:<p><pre><code> string.find(string.rep("a", 50), string.rep("a?", 50)..string.rep("a", 50))
</code></pre>
The only way to solve this is to track execution time <i>within</i> the native code as well (i.e. make them fuel-aware), and ensure that they abort immediately if they exhaust the fuel.