mirrors/arti.git/crates/tor-proto/src/channel, branch arti-v1.3.0 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.0 2024-10-09T17:21:09Z 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.) memquota: Introduce type aliases for channel->circuit RX queue 2024-10-09T17:19:38Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-09T16:43:33Z urn:sha1:6fd94b3d2547d54aa4e9bf5282f72064c6a6ef3f This is neater and will make changing the type (in a moment) less noisy. tor-proto: Make circuit->channel queues participate in memquota 2024-10-03T14:10:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-24T11:12:25Z urn:sha1:39935609efa1feb7512af8cf401865b90ffed786 We use the *channel*'s memquota account. This is arguably wrong, but it's hard to get right now. See #1652. Change the type of the queue, and the places it's constructed. The use sites can all stay the same. tor-proto: Plumb the ChannelAccount through to queue creation site 2024-10-03T14:10:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-02T16:24:59Z urn:sha1:939d291ed3792a5fd1392f4e2816de254ac1bc12 This gets it as far as the outbound circuit->channel mpsc queue creation. Also, we provide an accessor for it. tor-proto: Plumb the ChannelAccount through to queue creation site (pre-fmt) 2024-10-03T14:10:35Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-02T15:32:47Z urn:sha1:17f55b3302cb254506f0ce2a3421211b55eb5bc4 tor-proto: channel: Make construction fallible 2024-10-03T14:10:35Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-23T10:19:32Z urn:sha1:1861de6a00edd99c4354fc3b2eaaf88fec2d4fe6 Making a channel is going to involve making a memquota Participant, which can fail. tor-proto: Add a CoarseTimeProvider bound to all the SleepProviders (fmt) 2024-10-01T18:05:25Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-10-01T17:43:59Z urn:sha1:88d6f90b13fd8d0ddb538f833ff9531f8d308047 tor-proto: Add a CoarseTimeProvider bound to all the SleepProviders 2024-10-01T18:05:25Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-23T10:08:41Z urn:sha1:88554acf6ecfaeffa459e88857aefd2e6d4cd99f The memquota arranagements are going to use this. We *don't* apply this to Channel (or to other types that aren't already generic over SleepProvider). extract tor_async_utils::oneshot into ::oneshot-fused-workaround 2024-08-28T14:27:46Z Jim Newsome jnewsome@torproject.org 2024-08-22T19:20:36Z urn:sha1:46f7f01092e6ac55e3e958dc3a2228b1d36e26a1 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.