FileSystemSyncAccessHandle contains async methods

[janvarga]

Besides read and write which are sync methods, there are async methods truncate, getSize, flush and close, returning promises.

Does it make sense for the dedicated interface available only in dedicated workers to have async methods ?

[janvarga]

This is already being discussed here: WICG/file-system-access#323

People are actually requesting fully sync OPFS surface.

[ankoh]

After chatting with @tomayac and @hannes, I'd also like to summarize a few points here that we find noteworthy regarding the asynchronous methods in the synchronous access handles.

We recently entered WebAssembly territory with a browser version of the analytical database DuckDB (available at https://github.com/duckdb/duckdb-wasm).
Our initial focus was accelerating analytical processing in the browser and the current state of WebAssembly served us well for that purpose.
Now that we have a WebAssembly version of DuckDB running, we realized that this API proposal here holds a tremendeous (!) potential in the form of locally persistent fast embedded databases in browsers.
In its current state, however, the API won't really work for us as the mixed-in asynchronous methods will effectively prevent us from using the synchronous access handles.

The problem is the following:

1. Languages like C++ are still very weak when it comes to asynchronous I/O. We have coroutines in C++ now, but enough large C++ projects still model I/O through blocking I/O calls and multithreading which becomes seriously problematic with WebAssembly. If we leave threads aside for a moment (see 5)), we are forced to map blocking I/O in WebAssembly to synchronous browser APIs. Introducing asynchronous I/O in a system that is built around blocking I/O calls is very hard as it quickly requires all surrounding code to become a conceptual or explicit coroutine.
2. Our database DuckDB is built on top of a virtual filesystem abstraction and we use it today already to map WebAssembly I/O to, for example, synchronous XmlHttpRequests or the FileReaderSync. Feel free to check this yourself at https://shell.duckdb.org/ with a simple SQL query such as:
   SELECT count(*) FROM 'https://shell.duckdb.org/data/tpch/0_01/parquet/lineitem.parquet';
3. The proposed synchronous access handles have blocking read and write methods which is already great!
   However, open, getSize, truncate, flush and close are asynchronous which defeats the purpose of providing an API for a blocking context.
   We are calling all of these methods while sitting in a C++ call stack which is just incompatible to Javascript Promises.

I've seen 2 workarounds for this problem which are both insufficient today:

4. Automatic coroutines through Asyncify. This is an interesting approach but just not possible at a certain project size. These large-scale rewrite passes are not feasible when projects grow in complexity.
5. Dedicated I/O webworker that can use asynchronous APIs and communicates with Wasm through a Spin-Lock using SharedArrayBuffer Atomics.
   Even when ignoring the significant performance impact and scheduler disaster of modeling this through a spinlock, the even larger problem is the use of SharedArrayBuffers.
   SharedArrayBuffers have become very painful since Spectre and Meltdown as they force every user into cross-origin isolation.
   For some use-cases this might be acceptable, but there are enough cases where these headers are just not available.
   (E.g. just consider analytical tools that want to process user-provided external data - a dilemma with CORS)
   We therefore run DuckDB-Wasm by default only within a single WebWorker and without SharedArrayBuffers.

The vision:
We would love to make DuckDB-Wasm fully persistent in the browser.
This would give us:
A) IndexedDB on steroids, as we can build a full-fledged relational database with near-native analytical processing power.
B) Out-of-core processing, as we can spool to temporary files in the browser filesystem if we hit the heap limits of 2 (or recently 4) GB.

We think our points here are very similar to the arguments raised for the WebAssembly version of SQLite.
(Ref: WICG/file-system-access#323, @jlongster)
They are hitting a very similar barrier and would certainly profit from a fully synchronous API surface (for web workers) as well.

[tomayac]

@fivedots FYI.

[a-sully]

Thank you for the feedback! At this point it's clear to me that the split sync/async interface was a mistake. I'm in agreement that I'd like to see an all-sync* interface. I'm happy to put up a PR once #21 lands.

Note that changing methods from async->sync is a web-exposed change with potential breakage, since although awaiting sync methods is a no-op, any use of promise.then will break. I suspect this shouldn't be an issue given the overwhelming support we've seen from developers and other browsers (I know this will make @jesup very happy :) )

This change would affect at least #3 and #28

Chromium implementation bug: https://crbug.com/1338340

*all-sync meaning that all methods on the SyncAccessHandle (getSize, truncate, flush, and close) will be sync, but createSyncAccessHandle() (aka open) will still be async. I don't see us being able to change that

[jesup]

Good. It really never made sense to me that the API specifically to provide sync access was (mostly) async.

So... why can't createSyncAccessHandle (aka open()) be sync? This would require spinning event loops to wait for the IPCs needed to complete. However, that's not fundamentally different than what happens if the preallocated quota is exceeded by a write(), the content process will need to request more quota from the main process, and freeze the content in the meantime, since write() is sync. createSyncAccessHandle can only happen on a worker, so if can be frozen/spinning.

[a-sully]

That's a great question, and after doing a bit more digging I realized that some of the assumptions I'd held weren't as solid as I thought they were. The primary argument (and we can debate its strength) is that keeping this async retains some flexibility to put UI, such as permission prompts, on createSyncAccessHandle() (which can still be shown from a worker). In general, things that can show UI should never be sync, so making this sync would basically preclude us from ever being able to add UI here (such as if we ever want to allow SyncAccessHandles outside of the OPFS).

A counter-argument is that by the time you have a file handle to call createSyncAccessHandle() on, it's likely that any kind of "is this site/frame/worker allowed to access storage" checks that might involve UI in some browsers would have already been passed, or it could just error out if you don't already have write access to the file.

[rektide]

I know webassembly today is quite troublesome to use with async, but I do want to call out that webassembly folks are working hard on a variety of fronts. They're working to make component-model have good async interop (and bonus wasi meeting notes link). There's ideas to further significantly optimize wasm async performance, such as with https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md.

I know relief would not come right away even if this wasm work was all done, that there's still challenges. And I don't have specific use cases for why we'd want to be able to sequence these calls asynchronously. Yet, I feel like the proposal here is to make a less capable, less flexible system, with a more legacy style/feel, to help a target that might not necessarily need to exist for a long time. I'd prefer we wait & see or make a sync alternative, before making a generally less capable system, that hogs threads during not-fast i/o operations. Targeting some specific users ease of use at the cost of general flexibility feels like a violation of Extensible Web Manifesto.

As a web developer, having a bunch of sync apis show up that I cannot track & reason about normally seems intimidating, and doesn't feel like a pleasurable or modern experience for webdev. Many of these operations seemingly must block- flush, getSize probably. What are non-wasm webdevelopers expected to do? I don't see transferable appear anywhere in the accesshandles pr, so I don't believe I could do some of the work in the app, then send a handle to a DedicatedWorker to go handle a potentially running task. I could well be missing something, but, how, as a JS developer, am I supposed to safely call flush() without locking up the app/how am I supposed to use access handles?

Can we talk with some of the other wasm groups & see what we expect the future performance will be? There were a lot of very high visibility folks asking to prioritize wasm, and I do want to give them a no-compromise option. Maybe we should go back to where we were & have both sync & async interfaces available. In general, my inclination is that everything ought be async if at all possible. I'm hoping above all the js-promise-integration folks might have some cause to make us pause, make us less intent on spending effort warping ourselves into a odd & specific shape/form.

[fgmccabe]

@a-sully: As an outsider to this discussion, I need to take issue with:

Thank you for the feedback! At this point it's clear to me that the split sync/async interface was a mistake.

The web as a whole, and many other OSes, are 'moving' to an async world. The reason is that that fits real world requirements (responsive apps) much better. Sticking with a sync interface is not compatible with the Web.

There are wasm technologies coming that would make an async interface feasible. In particular, I am involved with JS-Promise integration. That is a standards-track activity; which makes it slower. However, our preliminary results seem pretty positive.