aboutsummaryrefslogtreecommitdiff
path: root/ext/wasm/sqlite3-worker1.js
diff options
context:
space:
mode:
Diffstat (limited to 'ext/wasm/sqlite3-worker1.js')
-rw-r--r--ext/wasm/sqlite3-worker1.js31
1 files changed, 31 insertions, 0 deletions
diff --git a/ext/wasm/sqlite3-worker1.js b/ext/wasm/sqlite3-worker1.js
new file mode 100644
index 000000000..3982ddaa2
--- /dev/null
+++ b/ext/wasm/sqlite3-worker1.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: 'worker1-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.initWorker1API());