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