5 ms·
A lease is usually a better choice than a lock. A lease has a time limit. A lock does not. Clearing stale locks manually is a PITA. I still assume, being a Web
by rdsubhas 2y ago
A lease is usually a better choice than a lock.
A lease has a time limit. A lock does not. Clearing stale locks manually is a PITA. I still assume, being a Web-scale contract, the lock would be automatically cleared if the browser is restarted or something. But honestly a lease makes users do better design from the get-go.
- mooreds 2y agoIs there a native browser API for leases?
- naasking 2y agoTime limits are a recipe for non-determinism. Non-determinism is generally not what you want.
- soulofmischief 2y agoPut another way, combining side effects and timers invariably causes race conditions.
- hn_throwaway_99 2y agoI might agree in other contexts, but not with the use case here and how the API is designed. It looks like the only potential for a "stale lock" is if somehow the async function passed to the request method hangs forever. But in web contexts I think that would be extremely unlikely for everyday use cases (e.g. most of the time I could imagine the async callback making remote calls using fetch, but normally that fetch has its own timeout). In contexts where it could happen, I'd argue it's better to make the caller explicitly handle that case (e.g. by using `steal`) than potentially leave things in an indeterminate state because a lease timeout expired.
- sweetjuly 2y agoThere is no real safe way to use lock hold timeouts. While a waiter can timeout and possibly handle failing to acquire the lock, there's no generic safe way to steal the lock from the holder after a timeout since the holder may still be accessing the protected resources/have left the resources in an inconsistent state. Adding a wait timeout which generates telemetry on a long wait may be useful for helping catch failures in production, but seizing the lock is almost always the wrong way to go about this.