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 --- test/fs.py | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'test/fs.py') diff --git a/test/fs.py b/test/fs.py index b4b0315b..fe7e4c13 100644 --- a/test/fs.py +++ b/test/fs.py @@ -217,6 +217,23 @@ def discovery(binary, embedded=False): client.write('/exec', b'Msg woken\n') reader.join(5) assert woke and woke[0].endswith(b' woken\n'), woke + # A pane's ctl takes acme's lock: a second open's lock waits until + # the holder unlocks, and nothing else waits on it meanwhile. + with Client(address) as other: + mine = client.open(f'/pane/{first}/ctl', 2) + client.rpc(118, struct.pack('