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 <[email protected]>

1 files changed, 9 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 64ac9ba1..b19a0a71 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -153,8 +153,15 @@ appends to the directory's `+Errors` pane. Holding `event` open redirects the
 pane's Look and Exec clicks to that client; writing a record back performs the
 action. `ctl` reads acme's window status line — serial, tag length, body
 length, a reserved zero, the dirty flag, the width in cells, the font and the
-tab width — and takes one verb, `get`, which reloads the buffer from the name
-it carries.
+tab width — and takes `get`, which reloads the buffer from the name it
+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 --
+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.
 
 The three range files `addr`, `dot` and `limit` each read the pair of offsets
 they also accept, so copying one onto another is all that acme's `addr=dot`,