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/ninep/events.zig | 2 ++ 1 file changed, 2 insertions(+) (limited to 'src/ninep/events.zig') diff --git a/src/ninep/events.zig b/src/ninep/events.zig index 8f66cf3a..cb31e2aa 100644 --- a/src/ninep/events.zig +++ b/src/ninep/events.zig @@ -121,6 +121,8 @@ pub fn noteRetire(p: *Pardes, pane: *Pane) void { tree.pty.shellGone(p, pane); p.fs.news = true; // a read held on its event or pty/data hears it went p.fs.listeners -|= pane.fs.readers; + // A write parked on its lock goes again, and finds the pane gone. + if (pane.fs.lock != null) pardes.turn.parked = true; if (pane.fs.unannounced) { pane.fs.unannounced = false; return; -- cgit v1.3