A connection as a pipe: a reader over the bytes the kernel received and a writer over a slab. Every call that must wait suspends the connection's coroutine, and the worker's loop resumes it on the completion, so a handler reads and writes in straight-line code. The HTTP engine is one such handler; ioxd_run_pipes runs one of yours on raw TCP connections instead.

Reading. The live bytes are the ones received and not yet consumed, always handed out as one contiguous span - in place in the kernel's buffer when they lie within one. read returns 1 with them once some are unexamined, otherwise it waits for more; examine says how many were looked at without being consumed, so the next read waits for more rather than returning the same bytes; drop consumes (never more than is live); keep consumes but leaves the bytes where they are and valid until release - it returns where those n bytes are now, or NULL when they would not fit the pipe's buffer (the pipe is then FULL) or n is more than is live; kept is everything kept since the last release as one span, wherever the reader has it now (a run that outgrew its kernel buffer moved to the pipe's own, so the span, not a pointer from an earlier keep, is what to read a whole message through); copy is the plain read into your own buffer. read and copy return 0 at the end of input, IOXD_PIPE_GONE on a dead peer, IOXD_PIPE_FULL when kept plus live bytes would exceed the pipe's buffer (16 KB). A handler that returns with bytes still in the writer's slab has them sent before the connection closes.

Writing: a slab, sent on flush. reserve n bytes to write into directly and advance by what was written, or write to copy in; send is write then flush. -1 once the peer is gone.