From 92ef244c8a24583896feb47c8c48ec40aa04ebb9 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Wed, 30 Sep 2026 13:19:44 -0300 Subject: 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 --- src/9p_io.zig | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'src/9p_io.zig') 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; -- cgit v1.3