Limiting compute is trivial on any modern operating system. On Linux you can create a second supervisor thread, block on a mutex with a timeout, and then if you timed out before acquiring the mutex you can just tgkill the runner thread. On BSDs it's even easier since you can just hand the runner thread port to your supervisor thread and, after you timeout, you can just set RIP/PC to whatever location you want without having to screw around with signals.

I'd love to better understand what you're describing. Thread-level compute limits generally seem like they need to be managed in some sort of cooperative fashion, otherwise you end up with the possibility of dangling locks and other kinds of corruption on forcible termination.

What signal are you sending to the running thread? What's the handler look like? How does that translate to terminating the thread? How do you do this forcibly (without cooperation from user code)? Schemes that I have seen look more like generating/ instrumenting polling/checkpoints into user code.

He's describing killing a thread using a watchdog.

This doesn't limit compute power of the thread.

It's an all or nothing approach; either the thread runs or is killed, which doesn't work (as you point out) for all circumstances where you want to limit the amount of compute pwr a thread can use.

They're describing sending a signal to a thread, not "killing" it. IIRC, the only thing tgkill is going to do for you is ensure which thread runs the signal handler. For example, if you send a SIGTERM, (IIRC), you will terminate your entire process.

You let it operate on a copy of the input data and check integrity afterwards. If it doesn't reach a valid state you discard it as failed/corrupted.

There are many pieces of process global runtime state that can get corrupted that are irrelevant to the input data.

You can get lucky and sometimes avoid corruption, but eventually you're going to hit something important like leaving a libc heap allocator mutex locked when you kill a thread in the middle of an allocation.

Yes, it is very easy to remove the entire standard library from lua. Could compute time be handled with signal handlers in at least some cases? If not, one (admittedly somewhat hard) option is to write a small lua to lua compiler that injects yields into loops and recursive function calls.