From 5d9a56d47a9cd5eefc4c8bf03709f2e96febb212 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Sun, 27 Sep 2026 20:25:26 -0300 Subject: A pane's ctl takes acme's lock and unlock A client doing an edit of several writes to addr and data had no way to keep another client's from landing in between. acme's window ctl takes lock and unlock for this (editors/acme/xfid.c:603-611): a qlock that blocks a second locker, owned by the fid that wrote it and given up when that fid is clunked, binding only clients that ask. pardes does the same: the open's record holds it, a second lock parks until unlock, close or the pane closing, and no other write is refused for it. Co-Authored-By: Claude Opus 5.5 --- src/fs-help.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/fs-help.txt') diff --git a/src/fs-help.txt b/src/fs-help.txt index 5f890d66..302e6538 100644 --- a/src/fs-help.txt +++ b/src/fs-help.txt @@ -42,4 +42,4 @@ Pitfalls, one each: Truncating tag clears the part you may edit; truncating dot or addr empties it. A terminal's body is a history snapshot frozen per open; pty/data is the live stream. A failing command is reported in the editor and in log, not as a write error; a bad line fails the write. - pane//ctl reads acme's window status line and takes one verb, get, which reloads from disk. + pane//ctl: acme's status line; takes get (reload), lock/unlock (a second lock waits for close/unlock). -- cgit v1.3