Getting underneath CraftOS

Is there a way to terminate CraftOS itself (including rednet thread) and still execute a program through the interpreter? This would release two threads which would allow greater performance by getting rid of unnecessary overhead for a program that will be running uninterruptedly. If achievable would one also lose parts of the _G table: namely os API, fs API, parallel API etc. and if so could this functionality be easily restored while keeping CraftOS in the grave? I ask the later part because I'm assuming that you would initially have to run a program in CraftOS, override much of _G and also catch CraftOS's thread on os.shutdown(). However I'm really not up for testing this out as I'm a bit scared that I may hang the computer and corrupt files etc. Any advice on this? Thanks

Too lazy to link to the actual forum threads, but you would want to look into something called top level coroutine override ;)/>

TLCO basically works by overwriting the printError() function and then crashing either of bios.lua's coroutines. It would normally show you the error and ask you to press a key prior to the whole computer turning off - but you can instead have printError() run whatever other code you like (eg, re-instate the original printError() and then shell.run() some other script).

You won't lose your os / fs / etc tables, either.

You do loose the shell api though, since it ships with the shell program.

Ah, that's a good point, and one I always forget - you need to use os.run() to start your new script.

If memory serves, isn't the whole CC environment run in one thread that just manages the computers and makes sure they yield? If what he's doing involves drawing to the screen a lot, then yeah TLCO is the way to go, but if what he's wanting is just raw speed, then no amount of overhang will diminish your speed as long as you aren't drawing to the screen for the majority of that.

Dragon53535, on 10 April 2016 - 06:10 AM said:

If memory serves, isn't the whole CC environment run in one thread that just manages the computers and makes sure they yield?

Sort of. To my understanding, each system gets its own thread within which its coroutine is executed. Only one thread is ever active at a time.

The TLCO technique doesn't actually bust out of the coroutines ComputerCraft is using to handle each system - rather, it busts out of the additional coroutines bios.lua starts up within those primary ones (you're always operating within a coroutine when dealing with a ComputerCraft system, no matter what you do). For most purposes it doesn't matter, but it's technically true that you'll get faster execution speeds in general via a TLCO (no matter what your script does). Quite a bit more, if my tests with coroutines are any indication.