mirrors/arti.git/crates/tor-chanmgr/src/mgr.rs, branch arti-v1.3.2mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.22024-11-27T19:11:58Ztor-chanmgr: remove immediately awaited async block expression2024-11-27T19:11:58ZSteven Engleropara@torproject.org2024-11-26T20:17:59Zurn:sha1:278a678c1f3cd36bdc805df439f01cde6dfa02f6
This shouldn't be needed anymore now that we use a `Defer`.
tor-chanmgr: use `Defer` in `AbstractChanMgr` to handle cancellations2024-11-27T19:10:41ZSteven Engleropara@torproject.org2024-11-26T20:13:24Zurn:sha1:935176f245e711fe270d86010c310e6c0a0410c4tor-chanmgr: remove panics in debug builds2024-11-12T01:27:27ZSteven Engleropara@torproject.org2024-11-12T01:23:04Zurn:sha1:cad2a7288bfb71b456e1f7690349cf721c421872
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 `upgrade_pending_channel_to_open`2024-10-24T18:08:19ZSteven Engleropara@torproject.org2024-10-21T17:02:20Zurn:sha1:aba584022de282cba738fd57ef80f335f2f15b34tor-chanmgr: improve cleanup procedure of pending channels2024-10-24T18:07:44ZSteven Engleropara@torproject.org2024-10-21T15:36:45Zurn:sha1:d1e90447a24460d4991033c198bedff20dc855c4
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"2024-10-21T15:40:41ZSteven Engleropara@torproject.org2024-10-21T15:32:31Zurn:sha1:90083e81fad3c6497a43d6a1f1fb4f1bc3c378e4
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`2024-10-15T18:01:24ZSteven Engleropara@torproject.org2024-10-15T14:46:35Zurn:sha1:af944b03f595057ce51d67184f185ac0cc30836btor-chanmgr: `PendingChannelHandle` removes the channel when dropped2024-10-15T14:50:09ZSteven Engleropara@torproject.org2024-10-15T14:46:32Zurn:sha1:f85bc3cf849109aaa2c4da9fc8c06e7173a0543ftor-chanmgr: added `PendingChannelHandle`2024-10-15T14:50:09ZSteven Engleropara@torproject.org2024-10-15T14:46:30Zurn:sha1:e7ee3ee55468b7e9aca990c5483b26bf24babe77
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}`2024-10-15T14:50:09ZSteven Engleropara@torproject.org2024-10-15T14:46:27Zurn:sha1:ca057e6f604096e0413768576a24b8db5cdcc2b2
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.