Need to break the computer to be able to "kill" it

As I said in another bug-thread, I'm making an emulator. I'm using a pre-bios.lua to init the "native" APIs, and sandbox the bios. I'm now currently working on the TLWY system. I wondered how CC handles TLWYs, soI poked a little in the cc.jar, and I saw, that the TLWY-system is a bit unstable. I managed somehow to break the TLWY system using this setup:

Spoiler

Note: DON'T try this out on servers that you don't own, or else [insert bad things here] might happen.
Warning: "while true do end"s everywhere :P/>

Spoiler

tlwytest

local cnt = 0
while true do
  print(cnt)
  cnt = cnt + 1
end

testy

while true do pcall(shell.run("tlwytest")) end

and then run testy in the shell.

What should happen:
Every 5secs and 100k lines the program should error with "Too long without yielding"

What happens:
It TLWYs almost randomly, or it breaks so much, that the "tlwytest" will run "endlessly" until you do something (for example rub the screen with the mouse, until it starts to purr)

Tested on CC 1.6x, it broke completely, I was unable to terminate/reboot/shutdown, so I had to reload everything.
On CC 1.7x, it froze my game almost instantly (it got to ~500). So I don't know if this version is affected.
On the second attempt, I held CTRL + T/R/S for 10-10 seconds, but the computer did not respond. I had to break it. After some time, MC stopped eating up the CPU-usage.

I know that this bug is almost unfixable, but I reported this just in case, if someone has a great mind to think about a fix.

I actually saw a report a while ago, which was almost exactly the same as this. They stated that it was not actually a bug, and therefore should not be "fixed" as fixing it would remove functionality.

Btw its 10 seconds and I do not know about the 100k lines.

No, it's not 10secs, it's almost completely random. It's range is about 0.8-infinite secs. In the code it says, it should be 5s + 1.25sec + 1.25sec the max running time without yielding, while checking for it every 100k lines. But if our little program wants to eat up the processor, it'll slow down the yielding process, or completely break the TLWY system.

MindenCucc, on 30 April 2015 - 03:17 PM said:

No, it's not 10secs, it's almost completely random. It's range is about 0.8-infinite secs. In the code it says, it should be 5s + 1.25sec + 1.25sec the max running time without yielding, while checking for it every 100k lines. But if our little program wants to eat up the processor, it'll slow down the yielding process, or completely break the TLWY system.

Unless if it is changed in the version of the code you are looking at, it is 10 seconds. I even checked the ask a pro, Read This Post Before Asking Questions to double check. If it is changed in the newest version, then that post should be updated. However, from experience i have never seen that error without the program running for 10 seconds or more without yielding.

Honestly if I were going to fix this, I would just make pcall error if the thing it runs errors with too long without yielding, which really wouldn't remove fuctionality.

The time sort of varies depending on the code being executed. To my understanding, ComputerCraft can "tap into" certain function calls and get them to halt, even if they don't usually yield; this is how it makes non-yielding scripts crash without killing the whole computer. But if the script that's running never calls those particular functions, CC does indeed need to make the whole system fall over. It'll wait a bit longer while it looks for one of its usual openings before doing this.

It's easier to just say "about ten seconds", especially when talking to newbies. The actual number doesn't matter much, as it's seldom people will write a script that has any reason to go even one second without yielding.

It seems that what's going on here is that the "tlwytest" script can be killed using the "easiest" method (as it calls print(), which makes use of term), but that simply gives control back to the "testy" script, which restarts it. ComputerCraft is making the assumption that a successful "soft abort" means the system will yield - but that's not really the case, so the system ends up being treated as if it's yielded when really it hasn't (when really CC should keep the timers going, and eventually shut the whole system down). Thus malicious users on a server can effectively block everyone else from using the mod.

That doesn't actually strike me as being that hard to fix, though. Just conjecture on my part. Dan'll know for sure.