Re: [w3ctag/design-reviews] Web Locks API (#217)

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):

```javascript
const lock = await navigator.locks.acquire('my-lock');
await doSomethingAsync();
await lock.release();
```

It seems odd to me that the promise returned by `acquire()` actually doesn't resolve when the lock is acquired but rather when it is released.  I also wonder if people will often forget to await on the async operation inside the callback:

```javascript
// 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 `acquire` is the wrong word - I'd consider `wrap`, `enclose`, `lock` or `lockFor`.

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?

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