Closed rustyconover closed 7 years ago
Thanks for the PR! Taking a look now
I'm wondering if a slightly different interface would be more flexible:
lock.isHeld(key, [fn])
returns a promise that resolves to a boolean indicating whether or not a lock is held given a particular keylock.on('release')
, and lock.on('acquire')
Nevermind, a release event wouldn't cover expiration in redis, and trying to resolve that with the current lock design would probably require key-space notifications being enabled. There's also probably no need for these events at all.
I can see lockCheck being abused to check state and conditionally acquire locks, which I think is an antipattern since such operations wouldn't be atomic. Could you give an example of your use case?
Gonna close for now due to inactivity, but thanks! :)
Check to see if a lock is held, but don't acquire it. Retries until the lock is no longer held.