Sleep and async and a debugger?

[TeamDman]

Proposal:

every 20 ticks do
  input from chest
  output stick to dest
  sleep 2 ticks
  output stone to dest
  sleep 2 ticks
  output sand to dest
end

My understanding is that Rust turns async functions into state machines where each resume point becomes a part of the program

async fn bruh() {
  println!("A");
  sleep(2).await;
  println!("B");
  sleep(2).await;
  println!("C");
}

gets turned into

enum ToRun {
  A,
  B,
  C
}
impl ToRun {
  pub fn run(self) {
    match self {
      A => println!("A"),
      B => println!("B"),
      C => println!("C"),
    }
  }
}

Right now, SFM builds an AST and executes it.

If we instead created a SFM virtual machine, it would be easier to distribute the execution of a program over multiple ticks.

This would make sleep and a line-by-line debugger easier to implement.

Cancellation safety / what happens if the chunk is unloaded before the program finishes?

0 every 20 ticks do
1   input 16 from src
2  output 5 to dest1
3  output to dest2
4 end

if there is a reload between 2 and 3, we would need to store the tracker information that tells us how much src has moved already.
Additionally, if 3 is the next statement to be executed, the program would have to reconstruct the input statement which is a memory of limited input slots, not itemstacks themselves.

If the "src" chest has slot 0 changed from 64x stick to 64x stone, when executing 3 after a reload it would complete the actions using the same slots and stuff.

Considering that we care about performance, having the option to pick either execution method and A/B test for speed would be nice.
Direct AST execution may be faster than calling program.tick() until returns done

If we have the SFM-VM break up complex operations into a simple instruction set, we could have a max instructions-executed-without-yielding config to prevent abuse of SFM to consume server resources.

Stack based VM?

[TeamDman]

register-based VM?

leddoo - are stack based vms really slower?

Rust Foundation - Rain: "Cancelling Async Rust" | RustConf 2025

TigerBeetle - Building a Distributed Protocol by Dominik Tornow

or just use raw java vm idk

[TeamDman]

if the game shuts down part way and then sfm updates and the intermediate representation of the program changes that will suck

[TeamDman]

https://discord.com/channels/967118679370264627/1535927002106822666/1535927002106822666
John
OP
— 4:25 AM
For example it would be EVERY 20 TICKS ECO 200 DO
and it would work by counting failed attempts in the background if every single operation within the every end envelope fails a certain amount of times back to back it will switch to the eco ticks until there is a successful action
— 4:26 AM
Modular routers has a button to do this too and it will be quiet good for servers to have this

---

SFM could still enforce the minimum tick interval by analyzing the code flows to determine if the cumulative sleep of any branch is below the threshold.

EVERY TICK DO
  INPUT 1 from chest
  OUTPUT to chest2
  if chest2 has > 1 iron_ingot then
    sleep 20
  else
    sleep 50
  end
END

could build in your own eco mode with it

if the program is sleeping, it skips scheduling the top-level every-tick-do behaviour.

every tick do
  input 1 from chest
  output to chest2
  sleep 19
end

would be equivalent to

every 20 ticks do
  input 1 from chest
  output to chest2
end

technically, all manager programs are abstracting under every-tick-do logic because the manager block entity ticks every tick anyways. giving users more control while still enforcing minimum intervals would be nice

[TeamDman]

actual implementation of an alternative eco interval specifier would probably be relevant to
#593 as well