Request for async FileSystemAsyncAccessHandles

[rektide]

With ongoing work developing V8 stack-swapping & works like https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md , it's quite possible the current work we've done to build a very special purpose high-speed sync interface catering to webassembly might not have the performance upside they do today.

We should try to understand where the platform is headed & what to expect will happen in the future, and use this information to reassess whether #21 's (and #7 's) current choice of preferring FileSystemSyncAccessHandle makes sense, and consider switching back to FileSystemAsyncAccessHandle with all methods being async & looking more like a normal web interface.

The performance concerns that pushed us to FileSystemSyncAccessHandle in the first place may not hold for another year. And then we'd be left with an api that doesn't look normal for no real good reason, other than historical accident. Let's try to gain some confidence that won't be the case.

[a-sully]

Whoops, I meant to mention this issue in #7 (comment). This issue is a good place to track interest in an async alternative to SyncAccessHandles

[jesup]

@rektide : when will that API be implemented in Chrome, Firefox and Safari? So far as I know (not on the JS team), Mozilla has done no work on this yet, nor do I see any involvement of anyone from Mozilla or Apple - just Alon (ok, and thus Google) and two other people. Also your comment is very conditional: "it's quite possible", "might not have the performance upside they do today", "may not hold for another year". (I think it's going to be significantly longer than that, but I'm not close to that work.)

I understand (and agree) that we don't want to clutter the web (and our browser codebases) with (more) outdated APIs; I'm not sure that even if that work was done that this API would be without use; it's a more straightforward match to WASM uses and some other usecases, so it may still have some utility. And it's very easy to implement a sync API in terms of an async API, so maintaining a sync API won't be a lot of extra code or work.

I do believe we should also provide async accesshandles.

[rektide]

Thanks all. @jesup, your analysis reads true to me on all fronts. Waiting on js-promise-integration seems not feasible at this point & it's quite probable we still would not have parity.

I appreciate your recognition about cluttering the web, and why you think this current sync handle has value anyways. Thank you for recognizing this. And I especially appreciate your comment at the end:

I do believe we should also provide async accesshandles.

This would be a great help for those of us not using emscripten/c++! 👍

[tlively]

We (the Emscripten team) are planning to experiment with OPFS + JSPI for single-threaded applications this quarter. Assuming we won't be able to get synchronous access to OPFS from the main thread, we will be interested in having an API for high-performance asynchronous access from the main thread. We would strongly prefer a BYOB API so we can read and write directly to and from the Wasm linear memory.