Re: [w3ctag/design-reviews] Sync Methods for FileSystemSyncAccessHandle in File System Access API (Issue #772)

The fully-synchronous interface* is shipped and in active use on all major browsers. Given the usage, I don't think deprecating this feature if feasible, if that's what you're asking.

You bring up a good point, though. Given the progress we're seeing with JSPI would we create the `FileSystemSyncAccessHandle` interface at all if we had to do it over again?... I'm not sure. The interface is commonly implemented as a very thin wrapper around a file descriptor. The sync-ness of the JavaScript API continues down the stack - once you hit C++ it's sync calls all the way down**. 

I'm not sure what the performance delta is between JSPI and Asyncify, but presumably the basically-no-overhead approach of `FileSystemSyncAccessHandle` is faster than what JSPI could possibly be. Which suggests that a sync interface has merits even in a world with JSPI :)

That being said, JSPI makes an async alternative to `FileSystemSyncAccessHandle` (which could be used from the main thread) much more attractive. WASM folks have already expressed interest in this: https://github.com/whatwg/fs/issues/41#issuecomment-1397685619

*note that this specific issue only tracks making _the entire_ `FileSystemSyncAccessHandle` interface sync. It was initially shipped with a split sync/async interface, which, as I described, in https://github.com/whatwg/fs/issues/7#issuecomment-1201811600, was a "worst of both worlds" situation. By the time this issue was filed it was less a question of "should this sync API exist" but "how can we fix what we've already shipped"

**until you hit the device driver, at least. Though arguably the decision for browsers to implement the `FileSystemSyncAccessHandle` interface using [synchronous file IO](https://man7.org/linux/man-pages/man2/write.2.html) is just an implementation detail, since browsers _could_ choose to use [async IO under the hood](https://github.com/axboe/liburing)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/772#issuecomment-1557687555
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/772/1557687555@github.com>