From 73e797e3f31eb52b0074b86cd16949c827b75670 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Mon, 28 Sep 2026 10:46:11 -0300 Subject: 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 --- docs/fs.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'docs/fs.md') 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 -- cgit v1.3