Re: [w3ctag/design-reviews] Multiple Readers and Writers in File System Access API (Issue #845)

> We briefly discussed this during our F2F, overall - this looks good. However, we couldn't see how the lock is expected to behave when the document becomes not fully active, or if the rug is pulled from underneath (e.g. crash). Effectively, there doesn't seem to be a mechanism in place for recovery; or getting out of a stale lock state. Could you elaborate on what you have in mind here and possibly add that to the explainer?

For a page crash, all locks associated with that page will be maintained by a process associated with the user agent. So if the user agent crashes the lock is released. This is similar to how flock is owned by the file descriptor, so if the process that owns the file descriptor crashes, then the lock is released when the file descriptor is unallocated (https://man7.org/linux/man-pages/man2/flock.2.html).

Interaction with BFCache is already an issue without introducing the new locking scheme and is discussed here: whatwg/fs#17. From that discussion, we'd like to evict a page in BFCache only on contention of a fully active page's FSA locks with the BFCached page's FSA locks. I'll update the explainer to have a section explaining that.

> Also, the other implementer signal is a pointer to a long thread, where we can't really identify who is from which implementer. It would be helpful if there was at least a pointer to the actual comment from each implementer. (Ideally we'd want to see a standards position.)

We forgot to request standards positions. I'll do that now!

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

Message ID: <w3ctag/design-reviews/issues/845/1660877275@github.com>