WIP: Web Locks API initial implementation#417
Conversation
|
@tshemsedinov isn't it supposed to be compliant with the spec for Web Locks API? It defines two interfaces: |
|
Yes, but it's just proof of concept and WIP. @belochub I'll implement also |
8422a3b to
e4d9e46
Compare
| const prev = Atomics.exchange(this.flag, 0, LOCKED); | ||
| if (prev === LOCKED) return; | ||
| this.owner = true; | ||
| this.trying = false; |
There was a problem hiding this comment.
We can use mutex.queue.length > 0 instead
| return this.tryEnter(); | ||
| } | ||
|
|
||
| tryEnter() { |
There was a problem hiding this comment.
Perhaps we can merge tryEnter and enterIfAvailable by adding lock argument and a few checks?
| enterIfAvailable(lock) { | ||
| if (this.owner) return lock.callback(); | ||
| const prev = Atomics.exchange(this.flag, 0, LOCKED); | ||
| if (prev === LOCKED) return lock.callback(); |
There was a problem hiding this comment.
According to https://wicg.github.io/web-locks/#api-lock-manager-request when ifAvailable is true the callback must be passed a lock (boolean) argument that signifies whether it got the lock or not.
465e50b to
18bcd04
Compare
6c4674d to
92b1739
Compare
|
In new implementation:
|
618e7a5 to
c048cf2
Compare
Refs: #416