-
Notifications
You must be signed in to change notification settings - Fork 58
Web Locks API #217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@triblondon to write some notes here. |
I should note that the IDL link given is obsolete; IDL fragments have been rolled into the proto-spec.
Thanks for the attention!
… On Jan 16, 2018, at 8:47 AM, Daniel Appelquist ***@***.***> wrote:
@triblondon to write some notes here.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
This seems like a cool feature. I have some questions: I'm wondering why the callback based API that also seems to incorporate promises was chosen. Explicit release is documented as an alternate API that was considered but there isn't much on why you chose the callback API instead. I'd instinctively want this (explicit release): const lock = await navigator.locks.acquire('my-lock');
await doSomethingAsync();
await lock.release(); It seems odd to me that the promise returned by // Appears to work but actually releases lock before async operation starts
await navigator.locks.acquire('my-lock', () => doSomethingAsync()); The impact of this design decision seems to be that on average locks will err on the side of releasing too early rather than too late. Given that they are origin-scoped, and therefore late-releasing locks can only impact the author's own applications, I would think we could provide the more explicit version. I can imagine scenarios in which I might want to hold multiple locks, but in unconnected non-nested operations, which happen to overlap. That seems a lot easier to reason about with explicit locks. If we are to have the callback shaped API, which resolves upon release, perhaps Have you considered a built in timeout or do we consider AbortController to be the right way to expose the ability to do that now? |
The best places that captures the debate is at: w3c/web-locks#9 - the design started with explicit release, but evolved away in response to feedback from @domenic, @jakearchibald and others. The callback+promises approach sounds weird in the abstract and I was skeptical, but the resulting code ends up looking surprisingly clean. Agreed that you need to remember the It does make the API awkward when needing explicit lifetime control; you end up recreating the explicit API with explicit promise hi-jinx. (e.g. this shows up in tests quite a bit)
Definitely considered — it was an explicit option in initial API sketches. Having it built in allows for the lock manager to run the timer, which is an advantage if e.g. a page is janking. But AbortController appears to be a generalization, so exposing just that for now. We look forward to developer feedback once it's implemented. |
Worth noting also that this callback mechanism makes web locks inconsistent with all the other numerous lock related APIs. We've established four distinct patterns so far for acquiring a lock on something. Do we really need a fifth? |
I think web locks are very different from the type of locks listed in those comments; it's unfortunate that sometimes we use the same English word for two separate concepts, but I think that's what's happening here. In particular those are about locking other people away from using a resource (keyboard, pointer) or locking something in a certain position (wake, orientation). Web locks are about the CS concept of a lock/mutex. |
On the flip side, this actually seems a bit different from a lock/mutex, given that it's promise-based and thus doesn't block the execution stack (except for I also think it's still similar enough in concept that the API surface shouldn't be unnecessarily different. |
The TAG just discussed this at our London F2F meeting and concluded that:
const lock = new WebLock('lock-name');
lock.on('acquire', e => {
e.waitUntil(doSomethingAsync());
});
|
Thanks folks! I'll chew this over and work through it with others involved in the design. I really appreciate the attention. |
We've posted further feedback on their issue w3c/web-locks#35, and that about wraps this up. |
Hello TAG!
I'm requesting a TAG review of:
Further details (optional):
We'd prefer the TAG provide feedback as (please select one):
The text was updated successfully, but these errors were encountered: