#772: Sync Methods for FileSystemSyncAccessHandle in File System Access API

Visit on Github.

Opened Sep 9, 2022

Wotcher TAG!

I'm requesting a TAG review of Sync Methods for FileSystemSyncAccessHandle in File System Access API.

FileSystemSyncAccessHandle is a file primitive that provides performant access to local files. One of its main use cases is applications porting C/C++ code to Wasm; however, asynchronous calls are not fully supported on Wasm yet, and using Asyncify library as an alternative has substantially degraded performance. Also, a split async/sync interface is not ergonomic, as Wasm-based applications expect a synchronous, POSIX-like file API.

Therefore, the proposal is to update asynchronous getSize(), truncate(), flush() and close() methods in FileSystemSyncAccessHandle in File System Access API to synchronous method, in line with synchronous read() and write() methods.

This change can potentially cause breakage if async methods were used the Promise .then()/.catch()/.finally() methods directly. (If used with await, there is no breakage). However, the current usage of FileSystemSyncAccessHandle is very low (e.g. zero usage queried by HttpArchive, recent shipping on Chrome-only); therefore, the scope and the impact of breakage is expected to be very minimal. Also, FileSystemSyncAccessHandle was shipped recently on Chrome M102 and is in the process of being implemented in Firefox, so it is preferred to make this change as soon as possible before the API gets used more widely.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): whatwg (initial work was started WICG, but the relevant parts to this proposal have been moved to whatwg)
  • The group where standardization of this work is intended to be done ("unknown" if not known): whatwg
  • Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/whatwg/fs/issues/7 https://github.com/whatwg/fs/issues/28
  • Major unresolved issues with or opposition to this design:
  • This work is being funded by: Google

You should also know that...

  • FileSystemSyncAccessHandle is available in Worker-only, thereby all synchronous calls are invoked from Workers, not from window.
  • There is ongoing discussion and developer demand around supporting an Async-version of access handle (name TBD for this performant file primitive). Note that this proposal is about making all methods sync within FileSystemSyncAccessHandle, and separately, we plan on supporting an async access handle, which may be more appropriate for common use cases, following asynchronous design patterns.

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify [github usernames] https://github.com/whatwg/fs/issues/7 @dslee414, @a-sully

Discussions

2022-10-10

Minutes

bump plenary

2022-11-28

Minutes

Amy: Sync and async discussion... in the thread...

Sangwhan: I can comment on this as well... In the web NN api... ...Interesting work-around... sync APIs only available on workers... to mitigate the damage. We could incorporate that guidance into the design principles...? In the context of NN API that's fine.. The sync suffix guidelines maybe applies here as well. We do have to have a deprecation path for these things as well. Going to be difficult to remove later on.

Peter: it's not horrible to have sync stuff that's only on workers... possible to feature-detect on the main thread though?

Sangwhan: this would be implementation-specific... On Firefox and Chrome it's possible... We could solicit some feedback - worker-only enforceable?

Amy: question from littleDan in this thread... wondering how we should handle cases going forward...

Sangwhan: he was suggeting we could leave room for WASM promise integration... but that's not shipping yet. So we should wait for that until we make it a principle. Can loop him in to the design principles issues.

Peter: one concern: are we going down the path of adding a full posix layer to browsers?

Sangwhan: probably yes...

Peter: might be worth taking a step back and asking the question - is there a line that we need to draw?

Sangwhan: the posix model doesn't fit with the main web... the threading model doesn't quite work... main() loop paradigm not compatible with the web... This happens because we want to re-use code on the web, but a lot of it isn't compatible.

Peter: it leads down the path that browsers ship a complete copy of linux...

Sangwhan: there are companies that want to do this.

[Agreed that we should get into this issue, separately.]

Dan: we continue to bang on about developer compexity... this falls into that catetory. What are we trying to do here?

Hadley: What do we need to do on this?

Sangwhan: I'll dig up ongoing relevant work and we can carve out a separate discussion for that, as an architectural thing.

Also a design principle needs to be drafted and reviewed.

2022-12-19

Minutes

bumped to next year

2023-01-09

Minutes

bumped to C

2023-05-22

Minutes

Tess: they want to change it from async to sync because of wasm... "async calls not fully supported on wasm yet"... so ... that yet feels important to me. This is trend we see: Sometimes people want a new feature because some other feature isn't quite right... so this is a stop gap... right way is to fix the other thing... Isn't the right thing for WASM to make async calls work better?

Peter: in general I agree with you - but also, there has been lots of cases of people creating a stopgap which needs to be supported forever... sometimes the stop gap takes longer than fixing the thing they are working around.

Tess: that said, if this is an API to use from WASM and workers then sync might be the right shape for it... If they are design it only from workers or work like context ... then it might be more ergonimic... broadly share the concern with adding sync apis but maybe it's OK when you can't block the main thread?

Peter: I remember discusson on this - part of this is to make more of a POSIX like layer... seems like we're trying to ad POSIX layer across the web platform...

Tess: e.g. cross-compiling C code... if you can make porting to the web easier then maybe it's a good thing?

Peter: I raised a concern: is it a good thing to turn the web into a POSIX layer?

Tess: they did address my issue in a comment here... LittlDan commended in october that async should be available in WASM in the near future... Does WASM now have adaquate support? WASM Promises Integration is at Phase 3.

Tess:

<blockquote> What's the current state here? Given that the main motivation for this is WASM and the WASM people are saying they are working on it from their end, is it still necessary to have this feature? </blockquote>

Tess: leaves comment

2023-07-03

Minutes

Peter: we questioned the utility, they responsed with this already shipped in all major browsers.

Peter: not sure it's actively harmful. It's a foot gun but... there are async alternatives...

Dan: close as overtaken?

Amy: "satisfied with concerns" and keep an eye for deprecation in the future?

Peter: this is part of the whole "do we want to add an entire posix layer to the web platform"...

**we agree to close it with overtaken **

Rossen: why not "unsatisfied"

Peter: not harmful. They asked for tag review then it shipped.