-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limiting script execution time reliably #70
Comments
func registerSleep(ctx context.Context, l *lua.State) {
l.Register("sleep", func(l *lua.State) int {
ns := lua.CheckNumber(l, 1)
childCtx, _ := context.WithTimeout(ctx, time.Nanosecond*time.Duration(ns))
<-childCtx.Done()
// Check whether the run was terminated or the timeout expired.
select {
case <-ctx.Done():
// Run was terminated.
lua.Errorf(l, ctx.Err().Error())
default:
}
return 0
})
// Override time.sleep from goluago.
l.PushGlobalTable()
l.Field(-1, "package")
l.Field(-1, "loaded")
l.Field(-1, "goluago/time")
l.Field(-4, "sleep")
l.SetField(-2, "sleep")
l.Pop(4) // Pop the tables.
} Our most common blocking native functions also take an outer context. |
That seems reasonable and was the approach I took for now. It seems easier to control everything a script does which allows being timed out. |
While we're at it, some mechanism to limit the VM's RAM usage would be appreciated as well. |
I'm struggling to find a good solution to implementing a reliable mechanism to limit how long a script is allowed to run.
A lot of examples show using debug.sethook to check if a timer has elapsed every 100k instructions or so but this is not that reliable as a C call can block.
Another solution is to use alarm system call or setrlimit on lua in a new thread/process but that has its own set of drawbacks.
Has a script timeout been considered before as something we can set on the VM before executing a pcall?
The text was updated successfully, but these errors were encountered: