the directory lock is the kernel's, not a pid we believe

flock(2) on the lock file's descriptor replaces "write my pid, and
decide whether the pid in the file is still alive". The kernel drops
the lock when the process ends, however it ends, so there is no stale
krino lock to detect and no takeover to race over.

What that fixes:

- Two runs that both judged a lock stale could remove and recreate it
  and both believe they held it. Remove-then-create cannot be made
  atomic; there is nothing to make atomic now. Pinned by a test with
  eight callers over twenty rounds.
- A pid reused after a crash made the lock live for ever, and the
  message named neither the file nor the pid, so there was nothing to
  act on. The message now names both.
- Signal(0) reads EPERM as "not running", so a lock held by another
  user was taken over. There is no such judgement left to get wrong.

A run that waits for a held lock now says so first. Waiting is what
the spec asks for, but the wait has no timeout, and in silence it is
indistinguishable from a hang - I spent two minutes on one myself
today, waiting on a lock the window was holding.

Tests that faked a held lock by writing a file now hold a real one.

0 files changed, 0 insertions, 0 deletions