Request for multiple readers via access handles

[alshamma]

Our web app downloads large application specific static data files. They range in the 10kb to several hundred kb size. We use a variety of approaches to cache this data. We would prefer to store them in OPFS, and, to be able to share them between multiple tabs of our app. For example, if the user opens two tabs to our app, we want to have a single copy of the data. We would like to download the data once, and then be able to read using the OPFS access handles from multiple tabs. We prefer access handles for their good performance.

[jesup]

(I believe I know the answer to this): Do you need the ability to seek within these files? I presume performance reading (from WASM) is important here.

Adding an 'accessMode: read' to createSyncAccessHandle() would seem straightforward, and can leverage existing accessmode logic used currently for SyncAccessHandle and getWritableFileStream

[alshamma]

Yes, we do need the ability to seek within these files. Your assumption about the importance of the performance of the read operation is correct. :-)

[a-sully]

Is a read-only handle sufficient, or do you need a handle you can write to and read from (from multiple places) at the same time? To me, this becomes a more broad question around how we should handle file locking (#18).

#19 lays out a more general proposal that gives developers more control over locking behavior, among other things.

Taking this proposal a bit further makes me wonder whether we should allow things like multiple writers to the same file. An argument could be made that since this is intended to be a high-performance API, the browser should get out of the way and let the developer and underlying OS handle keeping file data consistent.

[alshamma]

We don't need to do read/write simultaneously. We typically write once and read many.

[tlively]

Taking this proposal a bit further makes me wonder whether we should allow things like multiple writers to the same file. An argument could be made that since this is intended to be a high-performance API, the browser should get out of the way and let the developer and underlying OS handle keeping file data consistent.

From Emscripten's point of view, allowing arbitrarily many readers and writers would be ideal. We aim to emulate a normal POSIX environment to make bringing applications to the Web as easy as possible, and any differences imposed by Web APIs become problems our users (or we) have to work around. Our user's applications already handle the challenges of simultaneous file access on native platforms, so the Web platform trying to protect them from those challenges causes more problems than it solves.

[szewai]

Taking this proposal a bit further makes me wonder whether we should allow things like multiple writers to the same file. An argument could be made that since this is intended to be a high-performance API, the browser should get out of the way and let the developer and underlying OS handle keeping file data consistent.

From Emscripten's point of view, allowing arbitrarily many readers and writers would be ideal. We aim to emulate a normal POSIX environment to make bringing applications to the Web as easy as possible, and any differences imposed by Web APIs become problems our users (or we) have to work around. Our user's applications already handle the challenges of simultaneous file access on native platforms, so the Web platform trying to protect them from those challenges causes more problems than it solves.

The web API needs to be interoperable, having the same behavior across different file systems or OS, so we probably cannot make this API the mirror of POSIX file system API, or any file system API. (We could provide interface that client needs, with clear definition of expected behavior.)
Based on that, I think allowing multiple writers would be a more difficult question than allowing multiple readers.

[tlively]

Even if the browser had to do something like serialize all accesses to a file to ensure that no inconsistent state (i.e. partially applied write) could be observed, that would still be much better than the status quo of allowing only a single writer.

[a-sully]

I think allowing multiple writers would be a more difficult question than allowing multiple readers.

Yes, I agree. We can probably get away with just relaxing the exclusive locking requirement (i.e. making it possible to create a SyncAccessHandle with a read-only lock) to support multiple readers, but supporting multiple writers without a way to coordinate writes could get hairy.

As for whether we should support multiple writers in the first place... The current restriction of having one writer is not a problem for applications using this API, since single-paged applications can route all write requests through the same dedicated worker. But this restriction imposes architectural constraints that are significant hurdles to building libraries on top of this API, since all writes have to be proxied through the same worker, even when there are multiple tabs open for the same origin.

Adding support for byte-range file locking would solve this problem, albeit while introducing quite a bit of complexity. It's unclear to me at this point whether this is something we want to pursue.

[tlively]

Is it possible for multiple instances of the same application open in multiple tabs to route accesses through a shared worker? If so, that's news to me and would make things significantly simpler. If not, the single writer limit is still painful at the application level, since having multiple tabs open to the same application is extremely common.

[a-sully]

Is it possible for multiple instances of the same application open in multiple tabs to route accesses through a shared worker?

Shared workers exist, but my understanding is they're not a context where we'd want to call sync APIs. You can postMessage between tabs of the same origin (a FileSystemHandle is transferrable in this way, but a SyncAccessHandle is not).

If not, the single writer limit is still painful at the application level, since having multiple tabs open to the same application is extremely common.

Sorry, I should have been more clear that I was referring to just a single-page application. You are correct that this is an issue for any use case with multiple tabs

[szewai]

I think allowing multiple writers would be a more difficult question than allowing multiple readers.

Yes, I agree. We can probably get away with just relaxing the exclusive locking requirement (i.e. making it possible to create a SyncAccessHandle with a read-only lock) to support multiple readers, but supporting multiple writers without a way to coordinate writes could get hairy.

Right, we need to figure out how to coordinate the sync writes from multiple writers first, which could be in different threads or different processes.

As for whether we should support multiple writers in the first place... The current restriction of having one writer is not a problem for applications using this API, since single-paged applications can route all write requests through the same dedicated worker. But this restriction imposes architectural constraints that are significant hurdles to building libraries on top of this API, since all writes have to be proxied through the same worker, even when there are multiple tabs open for the same origin.

Adding support for byte-range file locking would solve this problem, albeit while introducing quite a bit of complexity. It's unclear to me at this point whether this is something we want to pursue.

I'd prefer making analysis and adding support based on realworld use cases, like the Adobe example for multiple readers.
Otherwise we might create something that's theoretically good but not performant enough (due to complicated locking), not user-friendly, or not meets developer's need.

[a-sully]

I'd prefer making analysis and adding support based on realworld use cases, like the Adobe example for multiple readers. Otherwise we might create something that's theoretically good but not performant enough (due to complicated locking), not user-friendly, or not meets developer's need.

I'm glad you asked! :)

Developers want relational databases. A goal of the Access Handles project is to allow developers to bring their own database to the web. As mentioned in this recent article about WebSQL deprecation by @tomayac, Chrome is working with the SQLite team to bring SQLite to the web over WASM. In the shorter term this will allow Chromium-based browsers to finally remove WebSQL, but the vision (or my vision, at least) is that Access Handles are the primitive enabling an ecosystem of WASM-based database libraries to become the way sites store data on the web. Fulfilling this vision requires those libraries to support reading and writing data from multiple tabs.

This API becomes significantly less useful if it's slowed down by bloat. Something like byte-range file locking is not worthwhile if it would degrade performance.

[alshamma]

I totally agree with:

Something like byte-range file locking is not worthwhile if it would degrade performance.

From the Adobe perspective, the multiple-readers is the priority as it would allow us to share data and caches between tabs. In particular, this allows us to avoid downloads of large data files like documents and fonts when shared between tabs.

While we see the value in multiple-writers for libs like SQLite, it is not a priority.

I prefer we focus on performant APIs.

[jesup]

The discussion at the Breakout session on OPFS seemed to end with consensus on allowing an optional lock-type parameter, which defaults to exclusive, but allows taking a shared read lock, or no lock at all. This is in reference to SyncAccessHandles.
Should we also apply this to WritableFileStream (with a default of Shared)?