aboutsummaryrefslogtreecommitdiff
path: root/ext/wasm/api
diff options
context:
space:
mode:
authorstephan <stephan@noemail.net>2024-06-12 12:17:03 +0000
committerstephan <stephan@noemail.net>2024-06-12 12:17:03 +0000
commit01f07a61e47fbafd4d89b9ab2ee728dae4938515 (patch)
tree9cacb1dd33038ce6c2d9d7e2763572e98a287974 /ext/wasm/api
parent6975fc56f7b207cf22b8b011203fe042fae6ecb3 (diff)
downloadsqlite-01f07a61e47fbafd4d89b9ab2ee728dae4938515.tar.gz
sqlite-01f07a61e47fbafd4d89b9ab2ee728dae4938515.zip
Doc updates in JS code. No functional changes.
FossilOrigin-Name: 587ed3a5d283898ad0e67ccee86a0a4ccc432fa292c0a3534e9e6ec70a7b7780
Diffstat (limited to 'ext/wasm/api')
-rw-r--r--ext/wasm/api/sqlite3-opfs-async-proxy.js24
1 files changed, 20 insertions, 4 deletions
diff --git a/ext/wasm/api/sqlite3-opfs-async-proxy.js b/ext/wasm/api/sqlite3-opfs-async-proxy.js
index e671094f0..48cddd7ef 100644
--- a/ext/wasm/api/sqlite3-opfs-async-proxy.js
+++ b/ext/wasm/api/sqlite3-opfs-async-proxy.js
@@ -173,10 +173,10 @@ const installAsyncProxy = function(){
/**
If the given file-holding object has a sync handle attached to it,
- that handle is remove and asynchronously closed. Though it may
+ that handle is removed and asynchronously closed. Though it may
sound sensible to continue work as soon as the close() returns
(noting that it's asynchronous), doing so can cause operations
- performed soon afterwards, e.g. a call to getSyncHandle() to fail
+ performed soon afterwards, e.g. a call to getSyncHandle(), to fail
because they may happen out of order from the close(). OPFS does
not guaranty that the actual order of operations is retained in
such cases. i.e. always "await" on the result of this function.
@@ -293,6 +293,20 @@ const installAsyncProxy = function(){
times. If acquisition still fails at that point it will give up
and propagate the exception. Client-level code will see that as
an I/O error.
+
+ 2024-06-12: there is a rare race condition here which has been
+ reported a single time:
+
+ https://sqlite.org/forum/forumpost/9ee7f5340802d600
+
+ What appears to be happening is that file we're waiting for a
+ lock on is deleted while we wait. What currently happens here is
+ that a locking exception is thrown but the exception type is
+ NotFoundError. In such cases, we very probably should attempt to
+ re-open/re-create the file an obtain the lock on it (noting that
+ there's another race condition there). That's easy to say but
+ creating a viable test for that condition has proven challenging
+ so far.
*/
const getSyncHandle = async (fh,opName)=>{
if(!fh.syncHandle){
@@ -674,8 +688,10 @@ const installAsyncProxy = function(){
mTimeStart('xUnlock');
let rc = 0;
const fh = __openFiles[fid];
- if( state.sq3Codes.SQLITE_LOCK_NONE===lockType
- && fh.syncHandle ){
+ if( fh.syncHandle
+ && state.sq3Codes.SQLITE_LOCK_NONE===lockType
+ /* Note that we do not differentiate between lock types in
+ this VFS. We're either locked or unlocked. */ ){
wTimeStart('xUnlock');
try { await closeSyncHandle(fh) }
catch(e){