A caller takes one admission permit before launching, and the pool holds exactly three workers per permit, so holding a permit means both drains and the input pump are already free. Without that coupling a caller can start a child whose pipes nobody is reading, or block forever writing to one that stopped reading.
A request declared as waiting also takes one of all but one admission permits. The remaining process stays available for the ordinary request that observes or releases those waits, without increasing the total process or pump bound. An additional waiter is refused before dispatch, so its caller knows it was never registered.
The caller itself may be a virtual thread: on JDK 21 {@code Process.waitFor} takes a {@link ReentrantLock}, so blocking there releases the carrier. The drains may not be, for two independent reasons. A process pipe read is monitor-locked, and — more decisively — a library does not own the scheduler. Any unrelated code blocking inside a monitor holds a carrier, and drains that need a virtual thread to run would then never run at all.
Launching and closing are ordered by an explicit gate rather than a flag, because checking a flag and then acting on it lets a caller start a child after {@code close()} has already decided there was nothing left to destroy. ## Members - `ProcessTransport` (method) — A transport allowing four concurrent tmux processes. - `execute` (method) - `executeWaiting` (method) - `close` (method) - `ProcessStarter` (interface) - `ResourceNotReclaimed` (class) — A worker could not be recovered. Distinct from {@link IllegalStateException}, which this transport reserves for use after close.