database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-07-30 19:03:16 +03:00
Code Activity

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.

Browse Source 
FossilOrigin-Name: a61467d1fbb7a2804bfdc685a38e0b738747b9afd42c25a78a938b114a822f61
This commit is contained in:
stephan
2023-05-30 14:10:28 +00:00
parent e32fef1400
commit 73d806dc1f
3 changed files with 23 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
ext/wasm/api/sqlite3-opfs-async-proxy.js
View File

@ -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;
}