Slight doc touchup for [af41a1e6fc8b36e9bf65] based on feedback. No code changes.

FossilOrigin-Name: be7b1fc0c5d8cda971b471dfcb4637212bfff4f42b1e074077a381cc493d877a

1 files changed, 5 insertions, 6 deletions

diff --git a/ext/wasm/api/sqlite3-vfs-opfs.c-pp.js b/ext/wasm/api/sqlite3-vfs-opfs.c-pp.js
index 59a07aac7..ef36b6062 100644
--- a/ext/wasm/api/sqlite3-vfs-opfs.c-pp.js
+++ b/ext/wasm/api/sqlite3-vfs-opfs.c-pp.js
@@ -472,16 +472,15 @@ const installOpfsVfs = function callee(options){
       const t = performance.now();
       while('not-equal'!==Atomics.wait(state.sabOPView, state.opIds.rc, -1)){
         /*
-          The reason for this loop is burried in the details of
-          a long discussion at:
+          The reason for this loop is buried in the details of a long
+          discussion at:
 
           https://github.com/sqlite/sqlite-wasm/issues/12
 
           Summary: in at least one browser flavor, under high loads,
-          this wait() call can, on rare occasion, end up returning
-          'ok', which indicates that it's returning _without_ the
-          other half of the proxy having called Atomics.notify(). When
-          this happens, we just wait() again.
+          the wait()/notify() pairings can get out of sync. Calling
+          wait() here until it returns 'not-equal' gets them back in
+          sync.
         */
       }
       /* When the above wait() call returns 'not-equal', the async