Max # of instructions on VM

[d5]

Optional limit on the maximum number of executing instructions on the VM

[tmclane]

How would this be utilized?
Is this to stop a script prematurely if it is an infinite loop? Or is the idea that you could step out of the VM and then continue execution at the previous location?

[d5]

Intention was to prevent it from running too long. But suspending/resuming might be interesting too. Do you have particular use cases in mind?

[tmclane]

The use case I was thinking of was providing the ability to pause / resume running of a script.
Or to execute it single-stepping like a debugger or run to a specific line and stop/pause.

Perhaps there is already a way to do this?

My actual use-case was to run the script in a goroutine and have it interact with the main program through predefined functions exposed to the scripting environment. It would run in the background semi-independently and never exit. What would you recommend in this case?

[d5]

Without knowing the full details, my recommendation would be to expose a function (more specifically an object that implements objects.Object and objects.Callable interfaces so you can use it like a function from the script; an example), then have it block or do some async stuffs within the function to coordinate with your main goroutine. The Tengo runtime (single-threaded) does not enforce any time limits (unless you explicitly want to), so it's okay to call a blocking call from your script. Tengo has some supports to make it more safe to run arbitrary code, but, it's completely optional.

And, if, for any reasons, you still want some pause-resume scenario, take a look at Tengo REPL code. But it's more involved as it directly uses Parser, Compiler, VM (instead of Scripts).

[tmclane]

Thanks for the information!

I came across this project after playing with Anko and was curious what else was out there. I have yet to decide how I want to truly use any scripting language as of yet into my project(s).

That being said I like Tengo so far! I did take a look at the REPL code which is very interesting and gives me some ideas on other ways I might use it in the future. For the time being I think a straightforward load, compile, run usage will do what I am envisioning at this time.

[myndzi]

Out of curiosity: This issue is marked as "closed as completed", but I can't seem to find any reference to this functionality in the docs. Is it actually possible to limit the number of executed instructions?

[geseq]

No but I think the use case had a workaround. Did you have a specific use case in mind?

[myndzi]

Ugh, I need to get my notifications sorted out...

I'm looking for something I can embed in an application to run untrusted code, and would like to limit resource consumption to avoid DOS. I realize there's also a memory allocation problem potentially here, but infinite loops are one thing I'd like to avoid. I was originally looking at WebAssembly, but I was surprised to learn that there aren't terribly good options here (also on the memory front primarily, but for limiting instructions you also have to run the built code through a transformation and the related libraries don't seem particularly active)