# target.ServerGeneration

- **Module:** target
- **Package:** libtmux
- **Language:** Rust
- **Kind:** struct
- **Source:** https://github.com/libtmux/libtmux-rs/blob/f0e37052c232636b61d095817046e6bfc8f2ca40/crates/libtmux/src/target.rs#L286
- **Page:** https://libtmux.org/en/rs/latest/reference/target-servergeneration/

Which tmux daemon is answering on an endpoint.

[`ServerIdentity`] answers "where", and that is not enough to answer
"which": tmux reuses the socket file across restarts, so a replacement
daemon is indistinguishable from the one it replaced by path alone. It also
reissues ids from the start, so the replacement's first pane is `%0` too.

Holding a handle across a possible restart is therefore a correctness
question rather than a liveness one. A stale read fails harmlessly; a stale
*mutation* lands on whatever now wears that id.

The pid alone would not do. A replacement daemon can be handed the pid of
the one it replaced, so the start time is what makes this a generation
rather than a guess.

## Example

```rust
let guard = libtmux::test::TestServer::new().await?;
let server = guard.server();

// Capture the generation beside whatever ids are being held.
let generation = server.generation().await?;
let session = server.new_session("work").await?;

// Before acting on those ids later, confirm the daemon has not been
// replaced underneath them.
assert_eq!(server.generation().await?, generation);
let _ = session;

guard.shutdown().await?;
```

## Members

- `pid` (method): The tmux server process id.
- `start_time` (method): When that server started, to the whole second tmux keeps.