# cloud9

The `cloud9` package owns the 9P2000 wire format, client and server
connections, the file-server engine and the Unix/TCP/QUIC transports.
`build.zig.zon` pins a commit from `git.sr.ht/~gbrls/cloud9`, fetched into
`zig-pkg/` like any dependency. Re-pin with
`zig fetch --save=cloud9 git+https://git.sr.ht/~gbrls/cloud9#<commit>`, or
use `.cloud9 = .{ .path = "../cloud9" }` while editing both.

- The engine (fids, jobs, parking, flush, hangup) is cloud9's `fs.Server`;
  the control tree in `src/ninep/` is its backend. `src/9p.zig` names the
  editor's and the board's `fs.Options` (the editor's: msize 65536, 256 fids, 128 held reads a connection).
- Unix and TCP listeners run on cloud9's `serve.Runner` (`std.Io`: an accept
  task per listener, a reader and a writer task per connection, 16
  connections). Requests are answered on the connection's task, which takes
  the editor's turn (`pardes.turn`) while the editor waits for input or is
  out in a syscall. A request that would change a pane while the editor is
  mid-step parks (`Status.again`) and is retried when the editor rests. A
  read with nothing to answer yet is held by the core and answered through
  the ticket `Conn.hold` gave it, only while that park still waits.
- QUIC (`src/9p_quic.zig`, ALPN `pardes-9p`) still runs on the editor's
  poll loop in `src/9p_io.zig`, since cloud9's QUIC adapter is
  nonblocking-descriptor based.

Tests: `zig build 9p-test` (engine configurations), `zig build 9p-io-test
-Dquic=true` (transports and client). cloud9's own `zig build test`,
`transport-test`, `quic-test -Dquic=true`, `fuzz` and `differential` cover
the shared code.

## The posted-9P registry

`$XDG_RUNTIME_DIR/9p` is this machine's `/srv`: servers post themselves
there by name, and `9ns --mntgen` mounts the whole registry (default
`/mnt/9p`). A pardes whose socket is in the runtime directory posts
`$XDG_RUNTIME_DIR/9p/pardes/<name>`, a symlink to its socket (one directory
per program, as zmx posts its sessions); a socket that fell back to
`~/.local/state/pardes` is not posted. Stopping unposts the entry if it is
still ours. Posting first sweeps the group: an entry that is a symlink whose
socket refuses a connect (ECONNREFUSED) is removed with its socket; anything
else counts as live.

pardes does not dial the registry: `9ns` is the client, and `--mount` dials
resolve as always (a bare name is a pardes session, anything with a slash a
path). pardes binds its own socket instead of posting through `cloud9.post`,
because `post` takes only flat names and pardes posts into a group
directory. A reader of the registry must `stat` through the symlink.