ControlClient

Description#

This is what a semicolon group cannot be. tmux discards a group after its first failure, so a client has to infer which command failed; here each request is independent, so a failure discards nothing behind it.

Replies arrive in request order, so the writer sends one request at a time and matches its reply by position. A reply is the first block tmux writes for the request: an acknowledgement, which work the command deferred may outlive. What that command queued, as if-shell queues its branch, and what a hook ran, arrive as blocks of their own, and none of them is taken for the next request's reply. A deadline before the writer picks a request writes nothing; a deadline after that point ends the client because the next reply could no longer be attributed safely.

The reader and writer are platform threads. A library does not own the virtual-thread scheduler: a caller's CPU-bound task that never blocks keeps its carrier, and either thread unable to run stops the client from making progress. The reader only resolves replies and fills bounded subscription buffers; subscriber code runs on the thread that pulls a value.

Threads. #send() may be called from several threads at once: requests queue in the order they arrive and each caller gets its own reply. A subscription is read by one thread at a time.

Close it. The client holds an attached tmux client, which is what makes tmux push output to it, and closing is what detaches that client and stops its threads. A client that is forgotten does not hold the JVM open — its threads are daemons — and the attached tmux client exits once the JVM does, because it reads its commands from a pipe that closes with it. Until then it is listed among the session's clients like any other.