| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
For readability
|
| |
|
|
|
|
|
|
|
|
| |
We will soon have a `ConfluxSet` type. Some of its operations will
return `Bug` (for example, the method for getting the *only* leg of the
conflux set will return a `Bug` if the set has no legs, or more than 1
leg).
This conversion function will make it easier these errors to
`ReactorError`.
|
| |
|
|
|
| |
We are about to use this in the circuit reactor (instead of
`pollish_send_unbounded`).
|
| |
|
|
|
|
|
|
|
| |
We also pass along congestion signals that may or may not be used by our
congestion control algorithm.
Part of #534
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This reverts commit d73f8894551d37e3bc36947eccf0c6007ffc066e.
|
| | |
|
| |
|
|
| |
This reverts commit acc79ffb44343e52ecb72e27ee8843a63448ff5a.
|
| |
|
|
| |
This reverts commit 2fd105b79c25d919e32e53daf81cb369d1e44331.
|
| |
|
|
|
|
|
|
| |
I considered just using `FutureExt::fuse`, but that becomes a little
annoying since the future type is exposed through
`IntoFuture::IntoFuture`, which means `ReceiverFuture` would need to
wrap a `Fuse`. I figured it's cleaner just to implement the trait
directly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
WakersAlreadyWoken>`
|
| | |
|
| |
|
|
| |
`Receiver`
|
| | |
|
| | |
|
| |
|
|
| |
CancelledError>`
|
| | |
|
| |
|
|
|
| |
The old version had some issues, so this is a rewrite which uses
slightly lower level synchronization types (`Mutex` and `OnceLock`).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Update `StreamPollSet` to require that its streams implement
`PeekableStream`, and to not do its own buffering of values read from
the stream.
This avoids an extra layer of buffering for streams that already
buffer a value, and makes the interior state a little simpler and more
robust.
It does have a downside of making the API a little less convenient,
since the caller must do its own `poll_peek` call if it wants a
reference to the item.
* Update `StreamMap` to implement `PeekableStream` for
`OpenStreamEntStream`, as it must to satisfy the updated
`StreamPollSet` API. We have to somewhat constrain the
`poll_ready_streams_iter` API to no longer return both a reference to
the stream and the message. I don't see a way to return both
while satisfying the borrow checker. Luckily we don't really need both
anymore.
* Update the Circuit reactor to handle the updated
`StreamMap::poll_ready_streams_iter` API.
|
| |
|
|
|
| |
This was required to be the same type as `S::Item`. We can just use
`S::Item` directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bullied by clippy. I'm on the fence whether this is actually an
improvement, or whether I should add an exception.
```
error: consider using `Option<T>` instead of `Option<Option<T>>` or a custom enum if you need to distinguish all 3 cases
--> crates/tor-proto/src/util/stream_poll_set.rs:106:56
|
106 | pub fn remove(&mut self, key: &K) -> Option<(K, P, Option<Option<V>>, S)> {
| ^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#option_option
= note: `-D clippy::option-option` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::option_option)]`
```
|
| |
|
|
|
|
| |
This simplifies the bookkeeping a bit, and clears a path towards
updating the Streams in our StreamPollSet to directly respect flow
control.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We can actually return references here instead of `impl Deref`,
simplifying this code a bit and follow-on code to use this in
StreamPollSet.
|
| |
|
|
|
|
|
|
|
| |
Primarily I wanted to exercise the code path that we get a spurious
wakeup due to a future that was removed from the map later becoming
ready.
I also ended up merging ReadyFut and PendingFut into a more flexible
ValueFut to make this a little nicer.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of wrapping `FuturesUnordered`, which doesn't support efficient
access to its internal futures, keep the futures themselves in our own
HashMap, and use a custom Waker to be notified which futures are ready
to be polled.
*Almost* a pure refactor in this step - the implementation now requires
that keys are `Send + Sync + 'static` so that we can put them inside an
`Arc` and send them over a channel.
|
