mirrors/arti.git/crates/tor-proto/src/channel.rs, branch arti-v1.3.2 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.2 2024-12-10T19:20:57Z tor-proto: removed `Receiver::recv_clone` and implemented `IntoFuture` for `Receiver` 2024-12-10T19:20:57Z Steven Engler opara@torproject.org 2024-12-04T17:33:20Z urn:sha1:fe559c5aee31e88e6b0f071fd745a8e04846ccde tor-proto: update docs on `Channel::reactor_closed_rx` 2024-12-10T19:18:09Z Steven Engler opara@torproject.org 2024-12-02T19:35:13Z urn:sha1:cf06134369049ef08aecc4c4ea43a4cedd7ad25b This is no longer applicable with the new oneshot broadcast channel design. tor-proto: replace oneshot broadcast channel 2024-12-10T19:18:09Z Steven Engler opara@torproject.org 2024-12-02T16:52:24Z urn:sha1:227c9c7c4e5c6cc1d171a4a1c865e05c32fb4274 The old version had some issues, so this is a rewrite which uses slightly lower level synchronization types (`Mutex` and `OnceLock`). tor-proto: replace `Channel`s "closed" state handling 2024-12-10T19:15:16Z Steven Engler opara@torproject.org 2024-11-26T02:54:44Z urn:sha1:09d7bce115179c3b7c4cb55cd1e0127fbe9e9929 Previously `Channel` had two concepts of "closed". There was an atomic flag that was set to `true` at the end `Reactor::run`, and an experimental oneshot channel where the sender was dropped when the reactor was dropped. This commit consolidates these two using the `oneshot_broadcast` module. This means that the behaviour is consistent between both "closed" statuses (`is_closing()` and `wait_for_close()`). A channel is considered closed when its reactor is dropped. This also helps progress towards making the channel reactor cancellation safe (see arti#1756). tor-proto: move `ChannelDetails::reactor_closed_rx` to `Channel` 2024-12-10T19:15:16Z Steven Engler opara@torproject.org 2024-11-26T02:35:34Z urn:sha1:36f178023188fefb8c43a0044a39350cd59fdb17 This doesn't need to be shared with the reactor. memquota: Fix circuit account lifetime (fmt) 2024-10-21T10:11:20Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-21T10:09:34Z urn:sha1:c017ccaf28fe1089ddd313fe0b874e6bc71546cd memquota: Fix circuit account lifetime (clippy churn) 2024-10-21T10:11:20Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-16T17:01:36Z urn:sha1:0be7b09361f1820179f9ec1f6d995c773b726433 Now that it doesn't call CircuitAccount::new() it has no error paths, and clippy demands we remove the Result, so it must once again become infallible. memquota: Fix circuit account lifetime 2024-10-21T10:11:20Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-16T15:08:49Z urn:sha1:09b80b32e316634324b0f99258df66773642da88 We foolishly made *two* CircuitAccounts, one of which gets immediately dropped. But we need to hold onto the account somewhere, because an mq_queue doesn't keep the account alive. Otherwise everything breaks when mq tracking is enabled. Apply deferred rustfmt churn 2024-10-09T17:21:09Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-09T17:21:09Z urn:sha1:fafe03628c3a6f670b052cfa8ac782843d72ea1a memquota: Use an mq_queue for channel->circuit RX queue 2024-10-09T17:19:41Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-09T16:45:07Z urn:sha1:bfa67c34da9357e412758507c312c6b92c2f3133 Fixes #1682. (This involves some noise in the tests.)