Restricting user script bad behaviour

SynapticBytes

I'm just skimming through the miniscript code for the first time, so excuse me if I ask some dumb questions that are obvious if I had a full understanding of the code.

In an embedded application, I'm just wondering how tightly controlled the interpreter is to stop bad user script behaviour. The main one I'm thinking of is infinite loops. I see in vm.step, that a line is pulled from the context, and DoOneLine executes on it. The code gets a bit trickier in that method. Is there any way for that "line" of code, to contain an infinite loop, or anything else that can hold control and not timeout when their timeslice is up?

I'm guessing that "line" being passed is the compiled opcode, more than what we physically see in the editor. So if they call their own function in a single script line, that will cause multiple passes through the interpreter, with the timeslice check on each part?

I guess what I'm wondering is whether, within a Unity implementation in particular, if I have to manage the actual script at all so it doesn't break my program, or whether I only have to manage my own intrinsics and data types with their own error handling? Of course I'll have to manage things like syntax errors and other reported errors during their script execution, but I mean things that aren't explicitly returned.

Thanks. Russell.

jstrout

Yes, the "line" there is really a single TAC (three-address-code, i.e. bytecode) instruction. There is nothing that user code can do to block the interpreter.

The exception might be, as you guessed, your own intrinsics that you add. If you let the users invoke some of your code, through an intrinsic or a custom get handler, and your code goes into an infinite loop, then of course this blocks the whole thread. So, don't do that. The section of the Integration Guide on writing intrinsics explains how instrinsics should carve their work up into chunks, and return a "not done yet" status, which will cause the interpreter to call them again and again (properly time-slicing via the main loop) until they report that they're done.

As long as all your intrinsics are written this way, even the most ill-behaved user code should be unable to cause serious problems for the rest of your app.

SynapticBytes

Sounds good, thanks.