summaryrefslogtreecommitdiff
path: root/crates/tor-chanmgr/src/mgr.rs
Commit message (Collapse)AuthorAgeFilesLines
* tor-chanmgr: remove immediately awaited async block expressionSteven Engler2024-11-271-23/+15
| | | | This shouldn't be needed anymore now that we use a `Defer`.
* tor-chanmgr: use `Defer` in `AbstractChanMgr` to handle cancellationsSteven Engler2024-11-271-18/+23
|
* tor-chanmgr: remove panics in debug buildsSteven Engler2024-11-111-4/+1
| | | | | | These were supposed to fail loudly in debug builds by panicking, but panics are mostly useless for debugging in async applications that use a runtime which catches panics. So we'll just log the error instead.
* tor-chanmgr: rename `replace_pending_channel` to ↵Steven Engler2024-10-241-5/+5
| | | | `upgrade_pending_channel_to_open`
* tor-chanmgr: improve cleanup procedure of pending channelsSteven Engler2024-10-241-30/+48
| | | | | | | | | | An attempt to make sure that there are no code paths which forget to remove a pending channel from the channel map. This also adds error-level log messages and panics during debug builds if a `PendingChannelHandle` is dropped without properly passing it to `MgrState::remove_pending_channel` or `MgrState::replace_pending_channel`.
* Revert "tor-chanmgr: `PendingChannelHandle` removes the channel when dropped"Steven Engler2024-10-211-2/+13
| | | | | | | | This reverts commit f85bc3cf849109aaa2c4da9fc8c06e7173a0543f. There were some small conflcits in `AbstractChanMgr::get_or_launch_internal`, so this wasn't a clean revert.
* tor-chanmgr: remove `handle_build_outcome`Steven Engler2024-10-151-28/+19
|
* tor-chanmgr: `PendingChannelHandle` removes the channel when droppedSteven Engler2024-10-151-6/+2
|
* tor-chanmgr: added `PendingChannelHandle`Steven Engler2024-10-151-18/+12
| | | | | This handle contains all of the details required to remove or replace a pending channel entry from the channel map.
* tor-chanmgr: refactor so we don't need `with_channels{,_and_params}`Steven Engler2024-10-151-53/+5
| | | | | | These methods on `MgrState` acquire a lock, and it's easy for calling code to also try to acquire the same lock within the closure, causing a deadlock. It's better to not expose these methods.
* tor-chanmgr: fix some incorrect commentsSteven Engler2024-10-151-4/+2
|
* tor-chanmgr: refactored `AbstractChanMgr::choose_action`Steven Engler2024-10-151-107/+27
| | | | | | | | This moves most of the channel map logic from `AbstractChanMgr::choose_action` to `MgrState::request_channel`. This is working towards being able to remove `MgrState::with_channels{,_and_params}`.
* memquota: Change ToplevelAccount to be an alias for Arc<MemoryQuotaTracker>Ian Jackson2024-10-151-0/+1
| | | | Fixes a TODO.
* tor-chanmgr: note API causes deadlocks under some conditionsSteven Engler2024-10-091-3/+4
|
* tor-chanmgr: minor code cleanupSteven Engler2024-10-091-5/+5
|
* tor-chanmgr: remove unused code pathSteven Engler2024-10-091-11/+3
|
* tor-proto: Plumb the ChannelAccount through to queue creation siteIan Jackson2024-10-031-1/+1
| | | | | This gets it as far as the outbound circuit->channel mpsc queue creation. Also, we provide an accessor for it.
* tor-chanmgr: Make a memquota::ChannelAcocunt per channelIan Jackson2024-10-031-5/+9
| | | | | This delivers a fresh account per channel to the places where channels are actually made, but doesn't pass them to tor-proto yet.
* memquota: Add a toplevel account in tor-chanmgrIan Jackson2024-10-031-0/+9
| | | | | | | | | Plumb through a top-level account. This doesn't have any channel-specific, circuit-specific or stream-specific accounts yet. tor-circmgr's and tor-hsclient's *tests* need fake account. In arti-relay, use a dummy account for now.
* tor-chanmgr: move channel selection logic to a new moduleSteven Engler2024-10-011-162/+4
|
* tor-chanmgr: improve readability of `choose_best_channel`Steven Engler2024-10-011-13/+45
|
* tor-chanmgr: support multiple channels for a relay IDSteven Engler2024-09-301-111/+243
|
* tor-chanmgr: add experimental `ChanMgr::handle_incoming`Steven Engler2024-09-111-1/+38
| | | | | | | | | The channel manager in the future will need to be able to receive incoming streams. The type of the stream depends on an associated type within `ChannelFactory`, so this commit exposes this associated type through several other types, eventually to the `ChanMgr`. The new methods are behind the experimental "relay" feature flag.
* extract tor_async_utils::oneshot into ::oneshot-fused-workaroundJim Newsome2024-08-281-1/+1
| | | | | | | | | | | | | | Having this in the `tor-async-utils` crate prevents us from doing both of the following without introducing a circular dependency: * using it in `tor-rtmock` (which we currently do, particularly in tests). * using `tor-rtmock` to test things in `tor-async-utils`. We don't do this yet, but it is generally sensible to do so. In particular we want to move the `stream_peak` module there, which is currently tested with `tor-rtmock`. Moving this into its own crate avoids this circular dependency.
* Make Channel non-Clone.Nick Mathewson2024-05-161-2/+2
|
* proto: Make Channel explicitly Arc<.>Nick Mathewson2024-05-161-10/+10
| | | | | | | | | | | | | | | | Previously, Channel was a type that you could Clone that implicitly its state. Now, Channel always appears as an Arc<Channel>. This change has several benefits: * It makes the relationship between Channel struct and the underlying channel more clear. * It enables Channel to participate in the RPC system, where everything has to be an Arc<.> * It enables us to have a Weak<Channel>, if we ever want to. * It will let us move various members out of ChannelDetails. We did this change a while ago with ClientCirc.
* Run maint/add_warning.Nick Mathewson2024-03-131-0/+1
|
* oneshot: Apply deferred rustfmt churnIan Jackson2023-10-111-1/+1
| | | | cargo fmt, precisely.
* oneshot: Use veneer in tor-chanmgrIan Jackson2023-10-111-1/+1
|
* Run maint/add_warning to add lint block everywhereIan Jackson2023-08-231-0/+1
|
* Merge branch 'clippy-allow' into 'main'Ian Jackson2023-07-111-0/+1
|\ | | | | | | | | clippy: Allow some of our existing code patterns See merge request tpo/core/arti!1396
| * Run maint/add_warning to actually apply new lint allowsIan Jackson2023-07-101-0/+1
| |
* | rng ranges: Use gen_range_checked().expect() in obvious cases (fmt)Ian Jackson2023-07-101-2/+3
| |
* | rng ranges: Use gen_range_checked().expect() in obvious casesIan Jackson2023-07-101-2/+3
|/ | | | In each of these, it is locally obvious that the range is nonempty.
* Allow clippy::unchecked_duration_subtraction in testsNick Mathewson2023-01-271-0/+1
| | | | | This panics on error, and we're fine with a panic on misbehavior in tests.
* test lint blocks: Add many many automaticallyIan Jackson2022-12-121-0/+8
| | | | | This is precisely the result of running the rune in maint/adhoc-add-lint-blocks.
* chanmgr: remove a now-stale TODO.Nick Mathewson2022-11-291-2/+0
|
* tor-chanmgr: Introduce the BootstrapReporter API, publicize ChanBuildereta2022-11-281-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | This commit makes the `ChanBuilder` type in `tor-chanmgr` usable by consumers outside of that crate, like the doc comment for `ChannelFactory` says you need to be able to do in order to turn your `TransportHelper` into something useful. As part of doing this, the `event_sender` its constructor takes needed to be dealt with, since it was a crate-internal type that came from inside the `ChanMgr`. Enter `BootstrapReporter`: an opaque wrapper around that sender, now provided as an additional argument to `ChannelFactory::connect_via_transport`. You can now construct a `ChanBuilder` outside this crate, and it'll still be able to report its bootstrap status by unwrapping this new type that's threaded through from the `ChanMgr`. (This was a fair deal of manually threading the type through all the layers in this crate!) Note that you cannot implement bootstrap updating using something that isn't `ChanBuilder` yet due to the type being entirely opaque (but, of course, we can figure out exactly what API the reporter should have later, and add that capability in).
* ChanMgr: Fix a few more conditional-compilation issuesNick Mathewson2022-11-231-0/+1
|
* ChanMgr: Implement functions that replace channel factories.Nick Mathewson2022-11-231-0/+8
| | | | | | | This commit makes it possible to replace the default channel factory (used when there is no PtMgr), and to replace the PtMgr. This is part of #659.
* ChanMgr: move the AbstractChanFactory into MgrState.Nick Mathewson2022-11-221-8/+6
| | | | | | We will want the freedom to replace this, so it needs to go behind a lock. We need to be able to Clone it cheaply now, so we're using an Arc instead of a Box.
* chanmgr::mgr::*: misc spelling fixes and normali[sz]ationsNick Mathewson2022-11-161-1/+1
|
* Fix up documentation that referred to a ChannelMap.Nick Mathewson2022-11-161-1/+4
|
* ChanMgr: Rename map.rs to state.rsNick Mathewson2022-11-161-9/+9
| | | | This is another pure renaming.
* ChanMgr: Rename ChannelMap to MgrStateNick Mathewson2022-11-161-2/+2
| | | | | | | | | We're doing this because the type now holds "all the mutable state in a ChanMgr", not just the map. This is a pure renaming; no documentation has been updated. Part of #606.
* Suppress two clippy::large_enum_variant warningsNick Mathewson2022-11-031-0/+1
| | | | These are newly present on 1.65. We can address them later.
* chanmgr: Add an error case if a final_attempt neither succeeds or failsNick Mathewson2022-10-181-0/+2
| | | | | This can happen in weird corner cases, so it's probably best to report it rather than having an "internal error."
* Refactor flow control in get_or_launch.Nick Mathewson2022-10-181-51/+94
| | | | | | | Now, instead of duplicate checks in various cases, we simply go through the loop one last time. This allows us to simplify some of our other logic around here.
* chanmgr: Split get_or_launch into sub-functions.Nick Mathewson2022-10-181-92/+95
| | | | | This function had grown huge and hard to reason about. Before I make it even worse, let's split it up.
* chanmgr: Refactor choose_action code into its own function.Nick Mathewson2022-10-181-86/+92
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 10:45:41 +0000