(I don't consider this technically polling but that's just semantics) and the other is in getSyncHandle(). This could give up some performance over many individually locked small transactions where the current code could reuse the access handle (or it might be negligible), but users can recover this optimization by collecting transactions in a PRAGMA locking_mode=EXCLUSIVE block. I think it is incorrect to say that the existence of one makes the other one "free" - the latencies will overlap but not perfectly - and I think you can avoid both of these latencies and the starvation (and the need for tuning the magic numbers for the intervals).įor database files, I believe that implementing xLock/ xUnlock using Web Locks as suggested earlier should remove both latency and starvation.įor journal files, I would try releasing the OPFS access handle in the xUnlock call for its database file. They both add latency when there is contention by sleeping while work is pending - getSyncHandle() for database files and waitLoop() for journal files - and additionally getSyncHandle() can cause starvation. One is the one you describe at waitLoop() (I don't consider this technically polling but that's just semantics) and the other is in getSyncHandle(). There actually appear to be two places where you "poll". Since we're polling constantly, anyway, we just interrupt the polling every half a second or so to give up any implicit locks we acquired. We have to poll anyway because the only way we currently have to fake synchronous access to the async OPFS API (recall that sqlite's API is 100% synchronous) is to use Atomics.wait() and Atomics.notify(). Thank you for the feedback! We are especially eager for it in these early days so that we can improve the API before imposing backwards-compatibility constraints in a future release. Before doing so i'll need to come up with a test app which runs in multiple tabs at once, or simulates it with multiple workers, so that we can evaluate the overall effectiveness of the current approach and WebLocks meaningfully. It's not at the very top of the TODO list, though. That's not an option i'm ruling out, by any means, especially after considering your first argument. WebLocks would require more development effort and may or may not perform better. My point in that is only that the polling option is "free" for us - we're just piggybacking on it to release any implicit locks. We can, if needed, drop that time to 100ms - pending real-world experience will guide us. You can wait asynchronously on a Web Lock, so no polling (and no having to tune your polling for different browsers and machines), which could address the problem described in this thread. Web Locks are supported everywhere OPFS is (and where OPFS is expected to arrive). p2pwdb-todo-example-journal : Original exception : Access Handles cannot be created if there is another open Access Handle or Writable stream associated with the same file.Ĭomlink.ts:265 Uncaught (in promise) SQLite3Error: sqlite result code 266: disk I/O errorĪt (sqlite3.js:9681:9)Īt new opfsUtil.OpfsDb (sqlite3.js:13111:37) Sqlite3.js:12084 OPFS syncer: xRead() async error: GetSyncHandleError: Error getting sync handle. p2pwdb-todo-example-journal : Original exception : Access Handles cannot be Sqlite3-opfs-async-proxy.js:63 OPFS asyncer: xRead() failed GetSyncHandleError: Error getting sync handle. p2pwdb-todo-example-journal DOMException: Access Handles cannot be created if there is another open Access Handle or Writable stream associated with the same file. The first tab succeeds, the second tab throws: sqlite3-opfs-async-proxy.js:63 OPFS asyncer: Error getting sync handle. I'm running into a case where I'm making a single write ( create table if not exists. The docs state that the OPFS VFS should be usable from multiple tabs so long as a transaction is not open and locking the file.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |