After 2 years of not using computercraft, I'm working on a "stateless" excavate program for turtles, because it annoys me that I have to reset my turtles every time their chunk unloads or I relog.
In this program, the state of the turtle is saved EVERY time before a critical action (movement, yielding) is done, so it can just continue where it stopped after starting again; you can imagine this is a lot of IO operations. (not only the coordinates, the complete context is being saved)
A computer_unload event would enable me to bring this down to only one state save before the computer unloads.

Of course, it has some downsides, for example the computer would take a bit longer to unload; but I think many people would have wished for a way to tell when their computer was about to shut down.
Probably some OSes, all in all some higher-level programs.

You can also modify os.pullEvent, so that by default, when a computer_unload event is catched, the computer immediately yields again.

You'd only be able to catch computer_unload when you use os.pullEventRaw.

This is something I've thought about several times, and it's one of those suggestions which is both immensely useful but incredibly problematic:

• One of the major issues is that you can't block the chunk from unloading, which means by the time this computer_unload/shutdown/whatever event is received, the computer's tile is gone. This means there's no peripherals, no os.setComputerLabel, no turtle.forward, etc...
  This mean you've suddenly got a computer executing with incredibly limited functionality. Obviously this isn't the end of the world, but it does feel rather clunky.
• It's possible to make a computer to run for 10 seconds before it's forcibly terminated. Just 6 computers abusing this functionality could hold up server shutdown for a minute. It'd be possible to require computer_unload handlers to finish in less time, but it doesn't fully alleviate the problem, just makes it slightly harder to abuse.
• The whole idea of running code after a computer has been destroyed is a bit iffy. Real life computers don't handle you pulling the power cord after all :). I guess there's an argument that computers shutting down when you walk away is already breaking the fourth wall, so we're just working around that.
• This still doesn't solve the root issue which is persisting Lua state. There will be times where the persisted information does not match the chunk (for instance a crash before the chunk could be saved) or times where the chunk is unloaded without the event being queued (server crash or closing the Minecraft window without pressing "Quit" in SSP).

Thinking about your mining program, perhaps you should use multiple files with each file being saved on different conditions, you only update the file if the value changes.

Also, does the turtle need to know the exact position or could it be left to calculate that when it reboots?

I didn't know you couldn't block a chunk from unloading, I agree that limited functionality doesn't really fit with computercrafts "way of doing things".

Well it'd be nice if real life computers COULD handle power outages though ^^ I mean most servers can handle them with a battery pack, so computers handling power outage may not be that unreal after all and certainly a nice thing to have.

But yeah, you convinced me; a computer_unload event could be abused too easily.

The first thing is a good idea @Lupus590 . I could find out coordinates and orientation using GPS, but that still doesn't really fix the root problem. I also had the idea to message the states to a pocket computer the player (= me) has in it's inventory. Then you could just tell the pocket computer when you're about to log out so it does a statesave.

Chunk upload delay could be achieved by making every computer be a temporary chunkloader, when the chunk would unload the computer keeps the chunk loaded just long enough for the chunk_unload event to be processed. Perhaps a better idea would be for programs to register a callback function for when the chunk unloads.

That goes back to the problem of a few computers greatly slowing a server shutdown.

Is there any reason not to implement vm-state saving though? (apart from it probably being a good amount of work)

The current version of Lua can't serialise functions and coroutines, having the capability to do that would make saving the VM a lot easier.

Is there any reason not to implement vm-state saving though? (apart from it probably being a good amount of work)

There are two issues at play here:

• Serialising the Lua state I've got a PR to the Cobalt VM, where I've been working on making it "resumable". However, merging it with ComputerCraft would require breaking changes to the public API. I was hoping to get this in during the 1.13 release, but given Dan has vanished, I'm not sure how likely this is.
• Serialising external state (such as peripherals, file handle, etc...). The trivial solution would be to add some sort of IPersistable interface, and serialise objects which implement this interface. Adding this would be relatively trivial, but getting consumers of the API to adopt it would take time.

That goes back to the problem of a few computers greatly slowing a server shutdown.

Well and what if we run real threads instead? We could let the user add a callback function and for every computer, which is unloaded, will be opened another thread, so that the computer_unload event would be executed parallel to all other current computer_unload events. If 6 computer try to slow down the server, than all 6 computers would end after 10 seconds.

will be opened another thread, so that the computer_unload event would be executed parallel to all other current computer_unload events

Sadly, this ends up being really abusable. Most Minecraft servers don't have more than 4 threads [citation needed] so, at some point, you'll end up eating into the server thread's time. This'll cause TPS lag.

One other thing to be aware of, is that chunks can sometimes be unloaded/reloaded in a very short space of time (see orphan chunks). Consequently, it'd be possible that a computer is loaded before the shutdown handler has finished. Technically that can happen now, but it's less of an issue.

I just think the "best" solution here is for programs which need some level of persistence to implement it themselves, and for us work on ways of implementing persistence into the main mod. I suspect anything else will end up being a hack that we'll later regret.

One other thing to be aware of, is that chunks can sometimes be unloaded/reloaded in a very short space of time (see orphan chunks). Consequently, it'd be possible that a computer is loaded before the shutdown handler has finished. Technically that can happen now, but it's less of an issue.

You could add some code that checks, when a chunk is being loaded, if there is anything that'd keep the chunk loaded. If there isn't, don't start the computers in the chunk.

Is it possible to save the Lua State? You could save it before shutting down and then bring it back, if the computer is loaded again. That would solve the computer_unload problem.

@sewbacca possible in newer Lua, but not in CC's current Lua.

See previous posts for more info.

Okay, maybe it isn't possible to save a computer state or to enable a computer_unload event, but what if the computer automaticly saves a lua table holding all needed information to resume the computer after startup? So we have a table, called for example _G.unbreakableInformation. This table would be saved when the computer shutdown or unload and loaded before the computer starts. That would save harddisk lifetime. If you don't like a global table, you could instead save the settings after unloading.

@Gabriel777 I'm interested to see how you achieved persistence for your turtle. I wrote an API which helps users make persistent programs and use another API to for turtle location persistence.

I already coded a Mining Turtle with some levels of data persistance, the code is very messy and need to be cleaned and fully translated to english, but I solved at least the "where am I?" problem with trilateration between turtles and some math, I'll share the code in CC forum as sooner as possible. Now talking about add this feature, correct me if I'm wrong but I do not think that it's responsability of CC code to do this kind of persistence, the game cycles will always be an issue and without breaking other things, persistence will fail sometimes, so I suggest that you have a host turtle or computer that has the duplicity of some of the turtle main data like "what program that am I executing and wich step of the execution was I?"