AskVM not timing out on infinite loops
See original GitHub issueAccording to the FAQ, the AskVM should timeout on infinite loops.
However running the following in the AskVM generates a hang (infinite loop) that does not seem to resolve.
const f = fun():any {
call(f)
}
call(f)
To replicate:
npm install askql
./askql
.editor
- Enter the above code
- Ctrl+D
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:6 (1 by maintainers)
Top Results From Across the Web
Infinite loops - throw a timeout error if execution exceeds ...
However when I call the infinite loops with the function test() and some console.log statements to show we have successfully called the loop, ......
Read more >Declarative timeout does not interrupt code running in infinite ...
Having some code running infinitely, but the timeout annotation(neither the class level nor testable method level) can interrupt the execution.
Read more >Debugging Infinite Loops | CodeHS Knowledge Base
The best first step for debugging an infinite loop is to comment out different sections or lines of code, then running the program...
Read more >Python While Loop Tutorial – While True Syntax Examples ...
An infinite loop is a loop that runs indefinitely and it only stops with external intervention or when a break statement is found....
Read more >Interrupting long-running HTTP requests or infinite loops
timeout expired (On spidermonkey you could use coroutines). ... > You received this message because you are subscribed to the Google Groups "nodejs"...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks @DavidSampson for posting this! You have definitely spotted a bug and we’re going to send a PR that solves it soon.
Speaking of this issue more broadly, every server indeed has different set of limited resources that it can devote to running a query (regardless of the query language). I agree that in case of AskQL this gets tricker, because more operations are possible - including endless loops, stack overflows, heap overflows - just to name a few. We’re going to address it by a) adding more different kinds of limits you can set for the VM b) allowing programs to query the information about their current limits at runtime so that they have an option to check the limits and adapt their behaviour.
These limits will include the number of operations, stack size, time allotted, and heap size. They are deterministic, yet their respective behaviour may vary by the server - especially the time limit which is subject to other workload. We’ll make sure that if AskVM returns an error, it will include all details possible on what limit has caused it, why, and what are the recommended steps for the developer. If there are other measures to help with development experience, we’ll look into these as well.
Please treat this as introductory input in this important discussion, more will follow. Thanks again, @DavidSampson, for your participation and creating this issue!
More generally, how does AskQL and AskVM plan to handle cases like this?
If there’s a limit to “steps” (beta reductions if this is a lambda calculus evaluator) or something similar, and the code written in the front end is O(n) where n is, say, the number of entries in a table, then a working query may suddenly start failing, and the only change is that a new entry was added to the table. That seems like a lot of hassle for the front end developer – you have to anticipate your query failing for reasons that are outside of your control.
If it’s a time limit, then you have the same issue, except now it’s even more non-deterministic, since server load will effect whether a query times out. It seems like that would be a testing nightmare.