A lock another open holds fails at once with file in use instead of parking

A contended lock parked until the holder unlocked, but through a kernel
or FUSE mount the kernel serialises writes to one file, so the parked
lock held up the holder's own unlock and close on that ctl, and the two
deadlocked. acme's qlock blocks; here the second lock is refused at once
with file in use (EBUSY) and the client retries, and nothing parks on
the lock any more.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 5 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index ac4e4b27..fee34941 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -219,8 +219,11 @@ whether the pane has the keyboard. It takes the pane's builtins (below),
 carries, and acme's `lock` and `unlock` (editors/acme/xfid.c:603-611), for an
 edit of several writes to `addr` and `data` that another client must not
 land in the middle of. As in acme the lock binds only the clients that take
-it: a `lock` while another open holds it waits until that open writes
-`unlock` or closes (or the pane does), and nothing else is refused for it --
+it: a `lock` while another open holds it fails at once with `file in use`
+(EBUSY), to be tried again, until that open writes `unlock` or closes (or
+the pane does) -- where acme's blocks, because through a kernel or FUSE
+mount a blocked write would hold up the holder's own `unlock` and close on
+that file -- and nothing else is refused for it --
 not a write to any other file, not the person at the keyboard. It belongs to
 the open that wrote it, so only that open's `unlock` is taken; a write on an
 open that cannot write (or the editor's own, on none) cannot lock. From a