Minor tweak to the OPFS async proxy to attempt to account for a spurious high-load console error message which was reported via the sqlite-wasm npm project.

FossilOrigin-Name: a61467d1fbb7a2804bfdc685a38e0b738747b9afd42c25a78a938b114a822f61

1 files changed, 16 insertions, 1 deletions

diff --git a/ext/wasm/api/sqlite3-opfs-async-proxy.js b/ext/wasm/api/sqlite3-opfs-async-proxy.js
index ddcad8f61..179a81635 100644
--- a/ext/wasm/api/sqlite3-opfs-async-proxy.js
+++ b/ext/wasm/api/sqlite3-opfs-async-proxy.js
@@ -818,9 +818,24 @@ const installAsyncProxy = function(self){
     }
     while(!flagAsyncShutdown){
       try {
-        if('timed-out'===Atomics.wait(
+        if('not-equal'!==Atomics.wait(
           state.sabOPView, state.opIds.whichOp, 0, state.asyncIdleWaitTime
         )){
+          /* Maintenance note: we compare against 'not-equal' because
+
+             https://github.com/tomayac/sqlite-wasm/issues/12
+
+             is reporting that this occassionally, under high loads,
+             returns 'ok', which leads to the whichOp being 0 (which
+             isn't a valid operation ID and leads to an exception,
+             along with a corresponding ugly console log
+             message). Unfortunately, the conditions for that cannot
+             be reliably reproduced. The only place in our code which
+             writes a 0 to the state.opIds.whichOp SharedArrayBuffer
+             index is a few lines down from here, and that instance
+             is required in order for clear communication between
+             the sync half of this proxy and this half.
+          */
           await releaseImplicitLocks();
           continue;
         }