feat: working coordinator architecture

Author: Robert-MacWha

.cargo/config.toml

@@ -1,16 +1,5 @@
 [target.wasm32-unknown-unknown]
 rustflags = [
     "--cfg", "getrandom_backend=\"wasm_js\"", 
-    "-C", "target-feature=+atomics,+bulk-memory",
-    "-C", "link-arg=--shared-memory",
-    "-C", "link-arg=--max-memory=1073741824",
-    "-C", "link-arg=--import-memory",
-    "-C", "link-arg=--export=__wasm_init_tls",
-    "-C", "link-arg=--export=__tls_size",
-    "-C", "link-arg=--export=__tls_align",
-    "-C", "link-arg=--export=__tls_base"
 ]
 runner = "wasm-bindgen-test-runner"
-
-[unstable]
-build-std = ["std", "panic_abort"]

.vscode/settings.json

@@ -0,0 +1,6 @@
+{
+    "rust-analyzer.cargo.target": "wasm32-unknown-unknown",
+    "rust-analyzer.check.targets": "wasm32-unknown-unknown",
+    "rust-analyzer.cargo.features": "all",
+    "rust-analyzer.procMacro.enable": true
+}

Cargo.lock

@@ -0,0 +1,16 @@
+[target.wasm32-unknown-unknown]
+rustflags = [
+    "--cfg", "getrandom_backend=\"wasm_js\"", 
+    "-C", "target-feature=+atomics,+bulk-memory",
+    "-C", "link-arg=--shared-memory",
+    "-C", "link-arg=--max-memory=1073741824",
+    "-C", "link-arg=--import-memory",
+    "-C", "link-arg=--export=__wasm_init_tls",
+    "-C", "link-arg=--export=__tls_size",
+    "-C", "link-arg=--export=__tls_align",
+    "-C", "link-arg=--export=__tls_base"
+]
+runner = "wasm-bindgen-test-runner"
+
+[unstable]
+build-std = ["std", "panic_abort"]

crates/wasmi-plugin-coordinator/.cargo/config.toml

@@ -12,10 +12,18 @@ keywords.workspace = true
 categories.workspace = true
 exclude.workspace = true
 
-[dependencies]
+[lib]
+crate-type = ["cdylib"]
 
-[target.'cfg(all(target_arch = "wasm32", target_os = "unknown"))'.dependencies]
-gloo-timers = { workspace = true }
-
-[target.'cfg(not(all(target_arch = "wasm32", target_os = "unknown")))'.dependencies]
-tokio = { workspace = true }
+[target.'cfg(target_arch = "wasm32")'.dependencies]
+futures = { workspace = true }
+thiserror = { workspace = true }
+tracing = { workspace = true }
+wasm-bindgen = { workspace = true }
+wasm-bindgen-futures = { workspace = true }
+web-sys = { workspace = true, features = ["Worker", "WorkerOptions", "DedicatedWorkerGlobalScope", "WorkerType", "MessageEvent", "ErrorEvent", "Blob", "BlobPropertyBag", "Url", "console", "TextDecoder"] }
+serde = { workspace = true }
+serde-wasm-bindgen = { workspace = true }
+wasmi-plugin-hdk = { workspace = true }
+wasmer = { workspace = true, features = ["js-default", "js-serializable-module"] }
+tracing-wasm = { workspace = true }

crates/wasmi-plugin-coordinator/Cargo.toml

@@ -73,6 +73,7 @@ Essentially a workarround for 3's issues. By having a coordinator worker that co
 
 The primary issue here is software architecture. Deciding how to split responsibilities between the main thread and coordinator.
   - If `host` is entirely in the coordinator, then the main thread must make a postMessage call for every host interaction, even those that don't involve compute workers. This probably won't be too slow, but will be annoying to setup (wasm-specific proxy that'll pass calls back and forth).
-  - If `host` is in the main thread, and only sends requests to the coordinator when compute workers are involved, then the coordinator will need to query the host whenever any computer worker needs to interact with the host. However, this will introduce similar problems to those outlined in the asyncify section and so is probably unacceptable.
+  - If `host` is in the main thread, and only sends requests to the coordinator when compute workers are involved, then the coordinator will need to query the host whenever any computer worker needs to interact with the host.
 
-Looks like we have our winner - Seperate coordinator with the host entirely in the coordinator! ~Yay to middleware~
+I'm going to go with the latter approach since it seems cleaner. There is some significant added latency in messages vs shared memory for inter-plugin communication, but it also results in a much much much simpler architecture and UX for consumers of the library.
+  - Namely - with the former approach, it would require placing consumer code in the coordinator worker.  That means consumers of the library would need to write and compile code for the coordinator, which means setting up rust nightly, atomics + shared memory, and having a seperate crate.  With the latter I can just bundle the compiled generic `.wasm` coordinator with the library for use as-is.

crates/wasmi-plugin-coordinator/README.md

@@ -0,0 +1,4 @@
+#![cfg(target_arch = "wasm32")]
+
+mod worker;
+mod worker_pool;

crates/wasmi-plugin-coordinator/src/lib.rs

@@ -0,0 +1,20 @@
+// console.log = function (...args) {
+//     self.postMessage({ type: 'Log', message: `${args.join(' ')}` });
+// };
+
+// console.error = function (...args) {
+//     self.postMessage({ type: 'Log', message: `${args.join(' ')}` });
+// };
+
+console.log("Worker JS initialized");
+
+import init, { start_coordinator } from "{sdk_url}";
+
+console.log("JS Glue loaded, initializing wasm...");
+
+init('{wasm_url}').then(() => {
+    start_coordinator();
+    console.log("Wasm module loaded, starting worker...");
+}).catch((err) => {
+    console.error("Worker Init Failed:", err);
+});