Web Locks API

Performance & benchmarking

• One user asks for performance benchmarks, especially vs Rust’s Tokio mutex in WASM.
• Others suggest writing custom benchmarks and recommend a JS microbenchmarking tool (mitata).
• Point made that many existing uses aren’t time‑critical, so users may not have measured performance in detail.

API design & ergonomics

• Several comments criticize the callback-based navigator.locks.request(name, async (lock) => ...) and the lack of an explicit release(); they find “hold until callback resolves” awkward when you want to keep a lock across wider scopes.
• Others defend the design as safer in a language without RAII, reducing the chance of forgetting to release.
• Multiple patterns are proposed to emulate acquire() / release() via promises and wrappers; some find these clumsy.
• Debate over hypothetical using / RAII-style syntax: some view it as clearer, others find RAII “too clever” and prefer explicit blocks or the existing callback.

Relation to Atomics and single-threaded JS

• Some argue the existing Atomics + SharedArrayBuffer APIs already cover low-level synchronization.
• Counterpoint: Web Locks are higher-level, origin-wide, and coordinate across tabs/workers without manual postMessage or shared memory, which is less error-prone.

Use cases discussed

• Coordinating OAuth refresh tokens across multiple SPA tabs so a one-time refresh token isn’t used twice.
• Guarding IndexedDB writes where transaction isolation is seen as insufficient.
• Sharing a single WebSocket/SSE connection via a worker.
• Preventing multiple crypto-mining tabs from competing for CPU.
• Preventing Edge “sleeping tabs” by holding a lock.

Locks vs leases and deadlocks

• One view: leases (locks with time limits) are preferable to avoid stale locks.
• Others argue timeouts introduce non-determinism and unsafe “stealing” of locks; better to detect and handle long waits explicitly.
• Concern raised that giving JS developers locks may increase deadlocks; response notes these locks don’t block threads, just leave promises unresolved, though affected app code is still broken.

Security, scope & naming

• Locks are origin-scoped and require secure contexts; commenters link this to modern “secure by default” design and to preventing MITM from abusing same-origin APIs.
• Worry about DoS if common lock names become well-known and pages intentionally hold them.
• Some think global lock names are risky; others say global naming matches the “super-global resource” concept.
• Questions about behavior across separate browsers or private sessions remain unanswered in the thread.