WASI: Implement experimental threading support

[Luukdegram]

This PR implements threading support for WASI. Note that WASI-threads is still an experimental feature and not all runtimes support it yet. The main goal of this PR is to not only add support for threads but also to gather feedback to improve the feature upstream.

Currently, the WASI-Threads proposal defines a single API entry which is wasi.thread-spawn, allowing us to pass a pointer to a context for later usage. This will ask the host to create an OS thread. Upon thread creation, an exported function wasi_thread_start will be called by the host environment. Providing us with a thread ID, and the original pointer we passed to thread-spawn. Although the host is responsible for creating and initializing the OS thread, it is up to the WebAssembly module to set up and initialize the memory for the thread. For this, we create enough memory to store:

• A guard page (to help prevent other threads from overwriting the memory of another thread)
  • This is done as best effort as there's no notion of read-only memory, yet.
• A new stack for the thread. (Set to user-specified size, or a single page, whichever is larger).
• A TLS segment
• Remaining memory required to store our Instance which holds metadata required to bootstrap the thread.

Upon thread creation, we then initialize the TLS segment and set the __tls_base pointer to this new TLS segment so loads and stores to TLS work correctly. We also set the stack pointer to the new stack that we created upon the call to spawn.

For WASI we ask the user to provide an allocator to ensure allocators are aware of any memory allocated by spawning a thread. Without this, it would be easy for the user to overwrite the memory we allocate during spawn as we can only grow pages sequentially and Wasm provides no way to tell what page is reserved and not. This also allows us to free the memory during join so the user's allocator can re-use memory that was previously allocated as there's currently no way in WebAssembly to free memory.
Unfortunately, this meant having to use a 'hack' during detach to free the memory (resetting the stack pointer upon thread exit to ensure we can free the memory using the allocator without using the stack that is being freed). The other option is to leak memory when a user uses detach. In the future, we can use memory.discard to handle freeing this memory and maybe get rid of the allocator from the API.

The next steps outside this PR are:

• Enable std tests, which requires us to:
  • Update CI Wasmtime to atleast v7.0.0
  • Update build.zig/test-runner to pass correct flags to Wasmtime to enable/run threading support.
• Add support for threads in WASI-LibC

For those wanting to play around with this, here's a test program with CLI invocation to both Zig and Wasmtime:

const std = @import("std");
pub fn main() !void {
    var threads: [3]std.Thread = undefined;
    var timer = try std.time.Timer.start();
    for (&threads, 0..3) |*thread, id| {
        thread.* = try std.Thread.spawn(.{ .allocator = std.heap.page_allocator }, myFunc, .{threads.len - id});
    }

    for (threads, 0..3) |thread, index| {
        thread.join();
    }
    std.debug.print("Total runtime: '{d}' ms\n", .{timer.read() / std.time.ns_per_ms});
}

fn myFunc(id: usize) void {
    std.debug.print("Sleeping {d} seconds on thread '{d}'\n", .{ id, std.Thread.getCurrentId() });
    std.time.sleep(id * std.time.ns_per_s);
    std.debug.print("Finished '{d}'\n", .{std.Thread.getCurrentId()});
}

Build thread.zig and run on Wasmtime:

zig build-exe thread.zig -femit-bin=thread.wasm -target wasm32-wasi --shared-memory -mcpu=mvp+atomics+bulk_memory --import-memory --export=wasi_thread_start --export-memory

wasmtime thread.wasm --wasm-features threads --wasi-modules experimental-wasi-threads

Output:

Sleeping 3 seconds on thread '1246793758'
Sleeping 2 seconds on thread '694100545'
Sleeping 1 seconds on thread '290362801'
Finished '290362801'
Finished '694100545'
Finished '1246793758'
Total runtime: '3010' ms

[andrewrk]

Nice work!