Concurrency/readwrite-unsafe with OPFSCoopSyncVFS?

[rkistner]

So far, OPFSCoopSyncVFS appears to be a great "default" option for a VFS - it ticks most boxes such as synchronous builds, supports multiple connections, has filesystem transparency.

One thing that would be great to add is concurrent read support, and maybe in the future even non-exclusive WAL support. I'm specifically referring to be able to do concurrent reads on different database connections (in different workers), not just having multiple connections open.

I saw the readwrite-unsafe mode is used in OPFSPermutedVFS and OPFSAdaptiveVFS. It looks like there was also some experimental VFS that used readwrite-unsafe mode.

Would it be possible to use readwrite-unsafe in OPFSCoopSyncVFS to get some concurrency support? Is there anything blocking this other than development effort? Of course this would only give concurrency in Chrome, but that would still be valuable (assuming other browsers would fall back to the current behavior).

[rhashimoto]

Would it be possible to use readwrite-unsafe in OPFSCoopSyncVFS to get some concurrency support?

Yes, it's possible. There are a couple ways that OPFSCoopSyncVFS could eventually use readwrite-unsafe mode:

A pretty simple way is to keep everything the same but not open/close the OPFS access handle every time the exclusive lock changes hands. This wouldn't produce any real concurrency - no accesses at the same time - but would improve the performance of multiple connections.

Another way is to change from exclusive locking to implement the full SQLite locking model including shared read locks. This would have performance trade offs because each step to a higher locking mode requires a retry, and now that would be three steps instead of one. It would allow multiple concurrent readers, so maybe faster for readers and slower for writers.

Even something like WAL is theoretically possible, but I have made a couple attempts at multiple readers with a writer and that is difficult enough without adding retries.

Is there anything blocking this other than development effort?

No, at least not that I know of.

One question, though, is how much benefit you would get for that investment. JSPI is expected to reach Chrome stable in Q2 (though it was also expected 2024 Q4 and 2025 Q1 🤪) and has been in Firefox Nightly for many months, which would ease some issues with asynchronous builds. I have been a little disappointed with JSPI performance on Chrome, but I haven't looked at it in a while.

Additional recent discussion of OPFSCoopSyncVFS is here.

[rkistner]

Thanks for the details! My takeaway is that shared read locks is possible, but it could be tricky to do without affecting performance of writes. Maybe I'll experiment a bit with that if I get a chance sometime.

One question, though, is how much benefit you would get for that investment. #115 is expected to reach Chrome stable in Q2 (though it was also expected 2024 Q4 and 2025 Q1 🤪) and has been in Firefox Nightly for many months, which would ease some issues with asynchronous builds. I have been a little disappointed with JSPI performance on Chrome, but I haven't looked at it in a while.

I'm also disappointed in the JSPI performance - I was quite excited when first hearing about the possibility. Right now the biggest advantage over asyncify seems to be the bundle size. Maybe the JSPI performance gets better over time, but I suspect that synchronous sqlite + OPFS is likely going to remain the best performing option for a while.

[rhashimoto]

I'm also disappointed in the JSPI performance - I was quite excited when first hearing about the possibility. Right now the biggest advantage over asyncify seems to be the bundle size.

I think that JSPI is faster than Asyncify when calling from WebAssembly to Javascript, but maybe slower in the opposite direction. I'm thinking that a less granular API would make things faster all around, but particularly for JSPI.

[rkistner]

I've been thinking about the locks and the overhead of "upgrading" locks, and one compromise might work: Instead of implementing the full granular lock system for each connection, you could have dedicated "read-write" connections, and "read-only" connections (you can already specify this in the sqlite3_open options). Read-write connections can always use an exclusive lock when any lock is requested, while read-only connections can limit themselves to using shared locks only. (I'm actually not sure if it's possible for SQLite to request an exclusive lock while in read-only mode - will need to check.)

This does not give the full granularity of SQLite's locking mechanism, and you won't be able to use two read-write connections to read concurrently. But if the application uses read-write and read-only connections appropriately, it should be able to get concurrent reads without the additional overhead you mentioned for writes. It should also be possible to keep the current implementation mostly the same, just changing the types of locks requested, as well as some tweaks to the lock request notifications.

[rhashimoto]

But if the application uses read-write and read-only connections appropriately, it should be able to get concurrent reads without the additional overhead you mentioned for writes. It should also be possible to keep the current implementation mostly the same, just changing the types of locks requested, as well as some tweaks to the lock request notifications.

I think you're right on all counts here!