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, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 2660bada..fe78fb19 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -179,8 +179,11 @@ files`.
 **Held reads.** A read with nothing to give yet (a followed `log`, `event`,
 `pty/data`, `pty/run` before its answer) waits in the editor and is answered
 when news comes. A second read on that open meanwhile fails `file in use`.
-A read the client flushed is dropped. Through a FUSE mount bash's `read -t`
-cannot time out: wrap the loop in `timeout N`.
+A read the client flushed is dropped. One connection holds at most 128
+reads at once; the next is refused `too many reads waiting: 128`. A mount
+(9ns) is one connection, so that is 128 followers through it, and the mount
+keeps answering everything else beside them. Through a FUSE mount bash's
+`read -t` cannot time out: wrap the loop in `timeout N`.
 
 **Stats.** Lengths are real (for `event` and `pty/data` the next record's,
 zero when none waits; for `log` what an open would freeze). The qid