diff options
Diffstat (limited to 'ext/wasm/sqlite3-worker1.js')
-rw-r--r-- | ext/wasm/sqlite3-worker1.js | 31 |
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()); |