server.Server.lock_channel

Self::with_channel_lock pairs this with the unlock, which is usually what a caller wants. A lock another locker holds waits for its turn, up to Server::default_timeout .

Errors

Returns an error when tmux refuses the channel name, and crate::ErrorKind::Timeout when the channel is still held after Server::default_timeout . A handle from Server::over_control_mode is refused, for the reason Self::wait_for_channel gives.

Cancel safety

Nothing is left held. The lock is taken in a task of its own, so a lock that is dropped -- or that runs out of time -- while queued behind another locker is not withdrawn from tmux, which cannot withdraw one: it is granted in turn and released at once. Between those two, later lockers wait as they would for any other holder.

Shutting the server down while such a lock is queued is the exception, because it kills the client: tmux then grants the lock to a client that is gone and every later lock on the channel blocks forever. A tmux defect (cmd_wait_for_unlock in cmd-wait-for.c), measured on 3.2a, 3.7d and 3.8-rc.