Evaluation quotas (limits)

We've discussed this for many years... and now, in A75, you can set secure to limit interpreter evaluation. This feature allows you to restrict server scripts (such as CGI) to a specific evaluation length to prevent runaway programs.

This example sets the limit to 50000 cycles, after which the program will immediately quit (the default behavior):

>> secure [eval 50000]
>> loop 100000 [next "test"]
<quit>

Also, for debugging you can use the more detailed form of secure:

>> secure [eval [throw 50000]]
>> loop 100000 [next "test"]
** Access error: security violation: eval
** Where: loop
** Near: loop 100000 [next "test"]

You can continue your debugging at the console, but secure will trap again on the next evaluation sample. To disable that behavior:

>> secure [eval allow]

When tuning your program, to determine how many cycles your code needs, you can use:

>> stats/evals
== 50403

However, add to that number a good margin of error for special conditions within your code. In many cases you will want to make it ten or twenty times larger, just to be sure.

A few notes:

The maximum evaluation limit is 2 ** 63(9e18).
The evaluation limit can be set only once and cannot be reset. However, for debugging after an eval THROW exception, you can use secure to disable the trap (use: [eval allow]).
The limit is approximate. It is sampled at regular intervals (to avoid slowing down evaluation.) The sampling period is 10000 cycles, so that is the resolution of the limit. For example, if you set the limit to 1, it won't trap an error until 10000.
If the program quits, the exit code is set to 101, the same as any security termination; however, we may want to use special codes to indicate the reason for the quit.
Some types of loops are not yet checked, but we will add them. For example, PARSE cycles are not yet counted.
Time limits are not yet supported, but may be added in the future. However, the cycle limit is better for most cases, because it is CPU speed independent.

10 Comments