search

whatwg / fs

File System Standard
https://fs.spec.whatwg.org/
Other
238 stars 20 forks source link

Queue tasks #3

Closed annevk closed 1 year ago

annevk commented 3 years ago

While preparing #1 I noticed that many promises are resolved and rejected from in parallel steps. Instead this has to be done from tasks. https://html.spec.whatwg.org/#queue-a-global-task seems most appropriate here, not entirely sure if this needs a new task source. Perhaps we should have one for storage in general?

a-sully commented 2 years ago

I'm supportive of this!

Seeing as AccessHandles is supposed to be the fastest storage primitive ever exposed to the web, does it makes sense to provide the Access Handles API its own task source? (in addition to one for storage more broadly)

annevk commented 2 years ago

Yeah, I think that could be reasonable. (Though we should probably sort out the model in #28 first.)

cc @smaug---- @domenic

a-sully commented 2 years ago

Revisiting this... All methods on the SyncAccessHandle are now sync (as per #7), so the argument made in my above comment about wanting a separate task source for this API is somewhat less relevant (although we'd like to eventually support an async version of SyncAccessHandles which is similarly performant - see #41).

It seems like we should have a new task source. @annevk do you have a preference for whether it's for this API or for storage in general?

annevk commented 2 years ago

I think ideally we consider which tasks need to happen in order across storage specifications and which can go out-of-order. And then put those in separate sources?

a-sully commented 1 year ago

Hmm good point. Thinking about this a bit more.... Writes using any storage API (including this one) can be rejected if the site is out of quota. So do all storage APIs need to use same task source for writes, since they all interact with the Quota Management API?

There are a couple of other [1, 2] storage-related task sources that I'm aware of, but they both queue operations that are read-only (i.e. don't affect quota)

annevk commented 1 year ago

That's a good point too.

So, the tasks are for informing the event loop about the result of a storage operation. So yes, write storage operations need to be in order (at least per site), but reporting whether that succeeded or not back to JavaScript (this involves tasks) doesn't necessarily have to be in the same order, but we might as well stick to a single task source for that I think.

a-sully commented 1 year ago

I was about to file an issue in whatwg/storage but stumbled upon https://github.com/whatwg/storage/issues/89. I don't personally understand much of the discussion happening on that issue - is there more to it than defining a new task source for write operations in the storage spec and then pointing all the storage API specs, including this one, to it?

annevk commented 1 year ago

It's better now that we have "queue a global task". We should probably define a wrapper around that called "queue a storage task" as well as the "storage task source" in the Storage Standard. Would you be willing to take that on?

a-sully commented 1 year ago

Filed https://github.com/whatwg/storage/pull/155 (which is erroring on something which doesn't seem to be my fault... :) )

a-sully commented 1 year ago

This was addressed in #95. All promises are now rejected/resolved on the new storage task source (in this spec, at least. See https://github.com/WICG/file-system-access/issues/420)