So You Want to Build a Language VM - Part 17 - Basic Threads

We should probably put a bit of thought into the details of this before charging ahead. A slightly more boring path, but our users will thank us.

Maybe.

OK, probably not.

Anyway, here is a possible workflow:

Questions arise when thinking about this:

I’m sure we could think of more, but let’s address the issue of tracking programs.

Whenever you execute a program on a computer running Linux, the operating system gives it something called a PID or process identifier. Linux guarantees that a PID is unique amongst currently running processes, non-negative, and between 1 and 32,767. After it reaches that number, it will begin to wrap around. If a process starts, gets a PID of 600, runs, then stops, 600 can be re-used.

When we start a REPL session, that is seen as one process. We can start OS threads in the background, but the OS does not know anything specific about what the Iridium VM is doing. If we want to track what code the VM runs and the results, we’ll have to do the same.

After making that change, all tests still pass, and if we try to give it a non-existent or bad file name now, we get:

Yay! Committing that, and we can go back to threading.

Let’s look at the signature for the thread::spawn() function:

pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T,
    F: Send + 'static,
    T: Send + 'static,

I am going to go over every line; a few new advanced Rust concepts are introduced here.

First off, notice that it is generic over F and T, and returns a JoinHandle<T>. What’s a JoinHandle<T> you ask? Great question! You can think of them as handles to the thread that is executing. It is not the thread itself, nor is it a simple pointer to it. Whatever the thread does, it has to return T.

The type parameter F is a FnClose, or function closure. The where constraint here indicates what types of functions are allowed:

They must implement Send + ’static', and FnOnce() → T. This means two things:

Here’s a simple example:

This means we have to change our VM::run() function to return a value. Easy-peasy:

/// Wraps execution in a loop so it will continue to run until done or there is an error
/// executing instructions.
pub fn run(&mut self) -> u32 {
    // TODO: Should setup custom errors here
    if !self.verify_header() {
        println!("Header was incorrect");
        return 1;
    }

    // If the header is valid, we need to change the PC to be at bit 65.
    self.pc = 65;
    let mut is_done = false;
    while !is_done {
        is_done = self.execute_instruction();
    }
    0
}

Back to the spawning pool, zergling!

The actual thread code itself is simple: vm.run(). get_thread will accept a VM, create a thread, which will execute vm.run() until it returns a value. This is simple because we are giving the thread ownership of an entire VM, so borrowck remains pleased. As we make the scheduler more advanced, we’ll have to get a bit more creative. For now, this will work:

For now, let’s copy the Linux model, and a assign each program a unique PID starting from 0 at zero. Let’s change our Scheduler structure like so:

Much like we gave the REPL shell its own VM, we can give it a scheduler, like so:

I’m not including the rest of the REPL functions again. You can scroll up for them. =)

Put it in repl/mod.rs as part of the REPL impl. Now we can make .spawn and .load_file much smaller:

We can start with a program but one instruction, HLT. You can find it under docs/examples/iasm. Let’s see what happens!

Doh. Time to debug.

<time passed>

Aha! You’ll notice in this section:

read_to_string returns the number of bytes it read, and reads the contents into the String provided as an argument. In our match statement, we converted that number of bytes into a string and returned. That is what the parser refused to parse.

The fix is simple:

Let’s try again:

After our assembler adds in the header and such, the final program size is going to be at least 65 bytes. 64 for the header, and 1 for at least the instruction. This looks like an off-by-one error in our program counter. That is, the program vector’s total length is 72, and it was off by one in the execution loop. I have a suspicion…​

Check out the run function in vm.rs.

See how it presets the program counter to 65? That means when the VM starts executing, the first thing it does is request the next instruction, which would be 66. The VM Is always ahead by one.

Change that to 64 and let’s try again…​

Hey, it ran and everything! In a background thread! Let’s check our registers to see if we can see the values:

Whaaa?

Because the VM ran in a background thread, it had its own set of registers and everything else. When we type .registers in the REPL, we’re still looking at the registers for the VM created and used by the REPL in the main thread.

In the background thread, when run terminated, all those data structures were gone…​like tears in the rain.

(Sorry not sorry)

Imagine my surprise when I ran cargo test at this point and it showed four failed tests: test_sub_opcode, test_mul_opcode, test_div_opcode, test_add_opcode. The error was:

Hello again, off by one error, my old friend. We meet again!

To fix it, I had to make a slight tweak to prepend_header in the vm.rs test module:

fn prepend_header(mut b: Vec<u8>) -> Vec<u8> {
    let mut prepension = vec![];
    for byte in PIE_HEADER_PREFIX.into_iter() {
        prepension.push(byte.clone());
    }
    while prepension.len() < PIE_HEADER_LENGTH {
        prepension.push(0);
    }
    prepension.append(&mut b);
    prepension
}

Can you spot the difference? =)