wasm refactoring part 2 of (apparently) 2: moved ext/fiddle/... into ext/wasm and restructured the core API-related parts of the JS/WASM considerably.

FossilOrigin-Name: 27f9da4eaaff39d1d58e9ffef7ddccf1e41b3726914f754b920e3e1fb572cba6

1 files changed, 31 insertions, 0 deletions

diff --git a/ext/wasm/api/sqlite3-worker.js b/ext/wasm/api/sqlite3-worker.js
new file mode 100644
index 000000000..48797de8a
--- /dev/null
+++ b/ext/wasm/api/sqlite3-worker.js
@@ -0,0 +1,31 @@
+/*
+  2022-05-23
+
+  The author disclaims copyright to this source code.  In place of a
+  legal notice, here is a blessing:
+
+  *   May you do good and not evil.
+  *   May you find forgiveness for yourself and forgive others.
+  *   May you share freely, never taking more than you give.
+
+  ***********************************************************************
+
+  This is a JS Worker file for the main sqlite3 api. It loads
+  sqlite3.js, initializes the module, and postMessage()'s a message
+  after the module is initialized:
+
+  {type: 'sqlite3-api', data: 'worker-ready'}
+
+  This seemingly superfluous level of indirection is necessary when
+  loading sqlite3.js via a Worker. Instantiating a worker with new
+  Worker("sqlite.js") will not (cannot) call sqlite3InitModule() to
+  initialize the module due to a timing/order-of-operations conflict
+  (and that symbol is not exported in a way that a Worker loading it
+  that way can see it).  Thus JS code wanting to load the sqlite3
+  Worker-specific API needs to pass _this_ file (or equivalent) to the
+  Worker constructor and then listen for an event in the form shown
+  above in order to know when the module has completed initialization.
+*/
+"use strict";
+importScripts('sqlite3.js');
+sqlite3InitModule().then((EmscriptenModule)=>EmscriptenModule.sqlite3.initWorkerAPI());