# server.Server.lock_channel

- **Module:** server.Server
- **Package:** libtmux
- **Language:** Rust
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-rs/blob/f0e37052c232636b61d095817046e6bfc8f2ca40/crates/libtmux/src/server/channels.rs#L117
- **Page:** https://libtmux.org/en/rs/latest/reference/server-server-lock_channel/

```
server.Server.lock_channel(self, channel: &str) -> Result<(), Error>
```

Lock a `wait-for` channel, blocking later lock attempts on it.

[`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.