You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit bcc54ec
Browse filesBrowse the repository at this point in the historyBrowse files
fix(memory): make stale-lock reclamation ownership-safe
Review found two races in the first cut: N waiters that all saw a stale lock
could each unlink it, so a slow waiter deleted the fast waiter's fresh lock
and both proceeded; and an operation longer than the stale threshold had its
live lock stolen, after which its finally removed the successor's lock. Both
reintroduce the lost update this PR exists to prevent.
- the lock file now holds the holder's token
- a live holder heartbeats the lock's mtime, so a long operation is never
mistaken for a crashed one
- stale takeover goes through rename(2): of N reclaimers exactly one wins,
the rest see ENOENT and wait on the winner's lock
- release unlinks only if the file still holds our token
Tests: eight simultaneous reclaimers of one stale lock keep 8/8 entities and
leave no lock behind; a slow heartbeating holder is not stolen from and its
release does not remove the successor's lock.
0 commit comments