This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Umpani's profile picture

At which point can a program get interrupted when a chunk unloads?

Started by Umpani, 07 September 2012 - 08:23 AM
Umpani #1
Posted 07 September 2012 - 10:23 AM
My apologies if this topic has already been discussed, i failed to find the relevant information in the forums.

I'm interested in whether a program can be interrupted at just any point or are there some sort of guarantees, like at the next pullEvent() or when a function returns?

Thanks in advance,
Umpani
KaoS #2
Posted 07 September 2012 - 11:12 AM
generally a program can be interrupted only when it pulls events with the CTRL+T terminate event but it can be shut down or restarted at any time as this is in the Java code and unloading the chunk should stop it immediately (I haven't tested the chunk loading thing but it makes sense)
Cloudy #3
Posted 07 September 2012 - 11:45 AM
On a chunk unload it can be stopped at any point.
Umpani #4
Posted 07 September 2012 - 05:24 PM
Thats regrettable, because it makes reliable state saving impossible. With the machine I'm currently working on i can circumvent the problem by reading the state from redstone input, but some sort of locking mechanism to postpone program termination until the state has been saved would come in handy someday. I'm not comfortable around machinery in indeterminate state. Especially when it has the potential for violent existence failure :D/>/>
Cranium #5
Posted 07 September 2012 - 05:42 PM
What kind of machines are you using? If it's a saving state issue, just create a save to state function, and a load to state function, and have the load be part of the startup code. I had difficulties with this at first with my programs, now I can save the state reliably, and know that as soon a sthe chunk is reloaded, it will startup from it's previous state.
Umpani #6
Posted 07 September 2012 - 06:17 PM
Your help is appreciated, craniumkid, but just saving the state is not my problem. It's saving the state reliably. When doing

changeState();
saveState();

there is no guarantee that the state is actually saved, because the execution could have been terminated right between those two statements. When changeState() changed something in the world, the program has no way of knowing about this change after restart just by loading the state from a file. It takes some kind of sensory input, like a redstone current. I'm probably a bit too anal with this matter, but i dislike writing programs which only work most of the time by design :D/>/>

P.S.: About the machine i'm using, its a CC controlled nuclear plant with 4 six-chamber reactors. The program controls the flow of SUC and replacement of reactor components and uranium/isotope cells based on a reactor layout which can be defined for each reactor.
Cranium #7
Posted 07 September 2012 - 06:32 PM
I see. I had assumed that your input was on/off, and you controlled that while you were at the console. You're saying that it changes variably while you are away, depending on information received from the reactor.
This would be great to see when you get it finished, hope it works out!
Sorry I'm not much help :D/>/>
Cloudy #8
Posted 07 September 2012 - 07:06 PM
Well if it is any consolation, chunk unloads only happen on the next tick - providing your code doesn't take longer than 0.05 seconds to execute, then you should be safe.
Umpani #9
Posted 07 September 2012 - 07:43 PM
Well if it is any consolation, chunk unloads only happen on the next tick - providing your code doesn't take longer than 0.05 seconds to execute, then you should be safe.

0.05 seconds is a very long time for a CPU, that should be enough, but it raises another question: is event handling synchronous with ticks, meaning that i get an event from pullEvent() roughly at the beginning of a tick?
D3matt #10
Posted 07 September 2012 - 08:12 PM
Well if it is any consolation, chunk unloads only happen on the next tick - providing your code doesn't take longer than 0.05 seconds to execute, then you should be safe.

0.05 seconds is a very long time for a CPU, that should be enough, but it raises another question: is event handling synchronous with ticks, meaning that i get an event from pullEvent() roughly at the beginning of a tick?
I'm not Cloudy, but I seem to recall that ComputerCraft and ticks are not related. LUAJ runs on a completely seperate thread than the minecraft world thread containing the ticks, so it should be completely independent of ticks. HOWEVER, if you're pulling an event triggered by the world (IE: Redstone), then yes that would happen on the tick because thats when the world updates, triggering the event.

Correct me somebody if I'm wrong.
Cloudy #11
Posted 07 September 2012 - 08:41 PM
Basically, any inbuilt event aside from key and char events are done on tick - so if for instance, your code executes after a redstone update, or sleep(), then it will happen at the beginning of the tick. Of course, within that tick all other computers which have an event waiting will also get delivered their events - however in a majority of cases, computers aren't doing anything complicated even when they receive an event, so it shouldn't affect anything.

Persistence should be coming in a future version built into ComputerCraft.
kazagistar #12
Posted 07 September 2012 - 08:45 PM
A quick and dirty solution would be to send a "suspend" event or something, and then kill 2 sec later?
Umpani #13
Posted 07 September 2012 - 08:59 PM
Thanks Coudy, i appreciate this insight into CC's internals. It's useful info: A state save should occur as soon as possible after an event is received to minimize surprises like rogue turtles forming skynet and seeking world domination or your piston printer wasting all your precious wool on 10.000 copies of creeper-butt :D/>/>