mirrors/arti.git/crates/tor-circmgr/src/impls.rs, branch arti-v2.0.0

circmgr: allow unstable_name_collisions lint for exactly_one()

2025-12-01T10:59:32Z

This silences a new nightly warning.

opentelemetry: Instrument a bunch of functions.

2025-11-24T16:28:07Z

These are all aimed at figuring out in more detail what's going on in #2079 and related issues.

circmgr: Implement expiration for long-lived tunnels.

2025-11-12T15:00:55Z

This code uses the algorithm of prop368: When a tunnel is sufficiently isolated, we want to expire it after it has been disused for a certain amount of time. The implementation is a little tricky, since we need to call an async function on ClientTunnel to look up the disused_since() check. We don't want to call async functions while holding locks, so we need to drop the TunnelList lock before we do the disused_since() calls, and the grab it again. As part of this change, I've had made expiration functions return the earliest time at which any tunnel might expire. We can use this in the future to spawn fewer expiration tasks, and scan the list of tunnels less often.

proto: Add a circuit module shared between client and relay impls.

2025-08-28T10:54:48Z

This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module.

Switch Cargo.toml files to edition 2024.

2025-08-07T15:28:36Z

First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.

Do not fully-qualify Sync.

2025-08-05T18:23:03Z

It's necessary and more verbose (and it's rather uncommon).

proto: Fix infinite recursion in ClientTunnel::extend().

2025-08-05T18:23:02Z

`AbstractTunnel::extend()` was calling itself endlessly because there was no `ClientTunnel::extend()` function to call.

proto: abolish path_ref() in favor of all_paths().

2025-08-05T18:23:02Z

Until now, we've been using `ClientCirc::path_ref()` to get the *only* path of a circuit. Now that `ClientCirc` is a handle to a tunnel reactor (which may or may not be multi-path), we need to decide for each call site of `path_ref()`, if we actually want *all* paths in the tunnel, or if we expect the tunnel to be single-path and thus want the *only* path in the tunnel. I've added two new APIs to address this: `all_paths()`, for getting all the paths in the tunnel, and `single_path()` for getting the only path in the tunnel, or an error if the tunnel is single-path.

circmgr: Return more type specific tunnel

2025-08-05T18:23:02Z

This is the first step towards making the circmgr return high level tunnel types (wrappers around ClientTunnel). Future commits will then modify each subsystems to use those specific types. They are split in order to reduce complexity. Signed-off-by: David Goulet

tunnel: Implement Buildable for ClientTunnel

2025-08-05T18:23:02Z

In order to pull this off, the Arc requirement needs to go away because the Arc is now within the ClientTunnel. This commit also has a rename of the CircuitBuilder to TunnelBuilder in order to reflect the change that it now builds a ClientTunnel. There is a slight rename in tor-proto as well just for accuracy. Signed-off-by: David Goulet