A connection holds up to 128 reads, the next refused "too many reads waiting: 128", and a mount beside 40 held event reads still answers

Two limits met. pardes parked 32 reads per connection and refused the
next with EAGAIN's C string, "Resource temporarily unavailable". 9ns kept
32 tags and 31 workers, each pinned by a held read. So 31 followers
through one mount took every worker, and `cat layout` then queued for
ever: the whole mount deadlocked.

cloud9 (705be665, pushed to sr.ht and pinned here) now refuses in words
past the cap. Its 9ns window is 256, so a mount always has workers past
what pardes holds. pardes raises its cap to 128. fs.md documents the limit
beside held reads. selfmount.py holds 40 event reads through the mount and
reads layout beside them. It times out with the 9ns installed before this
change and passes with the new one.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 5 insertions, 0 deletions

diff --git a/src/9p_io.zig b/src/9p_io.zig
index 5a68238c..0eaa2d7e 100644
--- a/src/9p_io.zig
+++ b/src/9p_io.zig
@@ -1542,6 +1542,11 @@ test "a change waits while the editor is out mid-step, a read does not, and the
     try testing.expectEqualStrings("after\n", pane.file.?.content);
 }
 
+test "a connection holds up to 128 reads, and the next is refused in words" {
+    try testing.expectEqual(@as(usize, 128), ninep.max_held);
+    if (comptime supported) try testing.expectEqualStrings("too many reads waiting: 128", Runner.Engine.e_waiting);
+}
+
 test "a held read is answered when the log has news, and a flushed one spends nothing" {
     if (comptime !supported) return error.SkipZigTest;
     const gpa = testing.allocator;