Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
tear-daemon — long-running tear server.
Owns sessions across client disconnects; exposes typed UDS RPC so
tear-client (or any consumer — mado at Tier 2, fleet operators
over SSH at Tier 3) can drive the [tear_types::MultiplexerControl]
surface remotely.
Wraps tear_core::InProcess rather than reimplementing — pane
semantics live in one place fleet-wide.
Architecture
A single UnixListener accepts connections. Each connection gets
its own OS thread that runs [serve_connection] — a synchronous
loop reading [Request] frames, dispatching to the shared
Arc<InProcess>, and writing [Response] frames back. The
per-connection thread approach matches the trait's sync surface
and avoids async-runtime overhead the daemon doesn't need —
InProcess already uses parking_lot for the registry lock, so
reads scale across threads naturally.
Lifecycle
[start] is the canonical entry point: it binds the socket,
creates the InProcess instance, spawns the accept loop, and
returns a [DaemonHandle] the caller can use to wait or stop.
Dropping the handle stops accepting new connections and joins
the accept thread; existing connections continue until the
peer closes them.