search

polterguy / lizzie

A script language for .Net and the CLR
https://ainiro.io/
MIT License
190 stars 27 forks source link

Lizzie programs can consume arbitrarily large amounts of resources #46

Open SapphireBrand opened 5 years ago

SapphireBrand commented 5 years ago

Basically, a computational process can create a request for an unlimited amount of memory/CPU. This is true even in a short program and even with a bounded recursive depth.

For the language to be predictable in a production setting, it should be possible to have limits on those resources.

A CPU limit is the most pressing concern for me, because I am looking at a TypeScript Lizzie, and so scripts will be running in a single thread per process (browsers have cooperative multitasking with a single execution thread for JavaScript). A badly behaving script will freeze the browser.

Memory usage is also a concern, but I don't know what we can do about it because Lizzie programs do not have their own heaps.

polterguy commented 5 years ago

This is a problem I have thought about previously actually, since among the scenarios I consider Lizzie could be useful, are "cloud execution", where for instance a service is created, that schedules a specified amount of CPU time per month to a 3rd party, where the 3rd party might not necessarily be 100% trusted.

Imagine something such as for instance Flickr search API as an example, where Flickr might want to allow for evaluating Lizzie code on their servers, binding to something allowing the callers to "filter" what the Flickr servers returns. Such services could be giving away for instance "x amount" of CPU time for free, and have a paid subscription for clients wanting more.

However, this problem is in fact already solved, since .Net allows for measuring execution time by using e.g. System.Diagnostic.Stopwatch during evaluation of a Lizzie snippet, in addition to using thread semantics to kill a thread after some amount of time - For then to make sure the caller's Lizzie code is evaluated on a thread, which is being killed if it doesn't finish its work within a reasonable amount of time.

So implementing this directly on Lizzie itself, creates a solution for a problem that arguably doesn't exist, and already have another alternative and probably better and more flexible solution from before.

Since such a service would probably be implemented using HTTP REST, the problem (for that specific case) with infinitely large code is also solved, since the web server can be configured to allow for a maximum size of its HTTP requests and HTTP responses. And in fact, some web serves could also configure request timeouts for each request automatically, without Lizzie having to do anything in fact.

So I am almost certain of that there exists (better) solutions for this problem already, than whatever I could possibly implement inside of Lizzie, and hence I am reluctant to create a (sub-optimal) solution inside of Lizzie for this problem, unless you or somebody else can think of a use case where it's really needed ...

But it's a very interesting problem ...

I'll leave this one open a week or two anyways, to allow you and others to raise opinions in regards to this, in case I am wrong ...

SapphireBrand commented 5 years ago

I thought about this approach. It think it might be best in C#. I think for TypeScript we will need something internal because there is no other thread that can terminate a runaway process.