| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
This warning is new in 1.83. Surprisingly, it only triggered once.
div_ceil was added in Rust 1.73, and our MSRV is 1.77, so div_ceil
is fine to use.
|
| | |
|
| |
|
|
| |
The docs here seem wrong, so I am updating them.
|
| | |
|
| |
|
|
|
| |
This is neater and will make changing the type (in a moment) less
noisy.
|
| |
|
|
| |
We'll need this in a moment.
|
| | |
|
| |
|
|
|
| |
This is necessarily a bit fudged, since a StreamReqInfo is full of
exciting things like ends of other MPSC queues.
|
| |
|
|
| |
Change the typss of StreamMpscSender and StreamMpscReceiver.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-proto: Introduce type aliases for some queues
See merge request tpo/core/arti!2484
|
| | |
| |
| |
| | |
This will make it a little easier to change the type later.
|
| | |
| |
| |
| | |
This will make it easier to change their types.
|
| | | |
|
| |/
|
|
| |
This prepares us to change the types of these queues.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
From
<https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2340#note_3062531>
|
| |
|
|
|
| |
In particular, clarify that stream-flow-control msgs don't get blocked
on circuit congestion control.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
As clippy points out otherwise, this no longer actually loops.
Since the iterator already guarantees that the messages it produces
are ready to send with respect to flow control, and we've already
validated that we can send with respect to the circuit window,
the loop, we can always handle the first item from the iterator.
i.e. this changes a `while let` to an `if let`.
|
| |
|
|
| |
This is no longer needed. Removing it shouldn't change any behavior.
|
| |
|
|
|
|
|
| |
When we've exhausted circuit-level SENDME window, iterating over streams
is likely to be a waste of CPU. Theoretically we might be able to send
some messages that don't count towards windows, but on balance it
doesn't seem worth it.
|
| |
|
|
|
|
| |
This prevents us from having to iterate over streams blocked on flow
control inside the circuit reactor, and potentially allows further
simplification.
|
| |
|
|
|
|
| |
Encapsulate flow-control into a separate object that partially abstracts
away the difference between window-based (legacy) flow control and
xon-based (prop324) flow control.
|
| |
|
|
|
|
|
|
|
| |
Since we no longer have an outbound queue for each hop, and instead
return an error here if there is insufficient circuit window to send a
message, there's no need to pre-check whether we have sufficient window.
If there's insufficient circuit window, we'll still return an error slightly
later, after failing to take from the circuit window.
|
| | |
|
| |\
| |
| |
| |
| | |
StreamPollSet: remove redundant type parameter V
See merge request tpo/core/arti!2334
|
| | |
| |
| |
| |
| | |
This was required to be the same type as `S::Item`. We can just use
`S::Item` directly.
|
| |/
|
|
|
|
|
|
|
|
|
| |
This was written for use in StreamMap, with an eye towards potentially
reusing it elsewhere.
We no longer use it in StreamMap, so it's currently unused.
Probably best to go ahead and remove it now and resurrect it if we
decide we want it later than to maintain dead code (or to make it more
widely available without more concrete use-cases).
|
| |
|
|
|
|
| |
This simplifies the bookkeeping a bit, and clears a path towards
updating the Streams in our StreamPollSet to directly respect flow
control.
|
| |
|
|
|
|
| |
This temporarily results in *more* bookkeeping, but is a step towards
putting the mpsc receivers back into `OpenStreamEnt`, and putting
the whole `OpenStreamEnt`s into the `StreamPollSet`.
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #1513
|
| |
|
|
| |
For debugging #1513
|
| |
|
|
|
|
|
| |
We no longer need this. StreamMap now supports handling only one
outgoing message at a time while ensuring no streams starve, so we no
longer ever pull messages out of the map when we're not actually ready
to send them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Refactors `StreamMap` to use `StreamPollSet` to manage its receivers
for mpsc streams.
* Extends `StreamMap` to support iterating only over streams that have a
pending outgoing message, and in round-robin order.
* Updates `circuit::reactor::Reactor` to use this functionality. It now
iterates only over streams that have a ready outgoing message, and
only actually "pops" a message that is ready to be sent.
This mildly simplifies the circuit reactor, but more importantly clears
the way to:
* Remove the "outbound queue" of messages that were pulled from stream
channels but that we couldn't send yet due to congestion control.
* Support opportunistic packing when preparing to send a relay message.
(proposal 340).
* Refactor the circuit reactor's `run_once` into futures that we can
`select!` over.
|
| | |
|
| |
|
|
|
| |
I seem to have mistyped this ticket number. We meant #1397
aka "Circuit reactor isn't great", not some release ticket.
|
| |\
| |
| |
| |
| | |
RFC: Provide and use SometimesUnboundedSender in circuit reactor
See merge request tpo/core/arti!2172
|
| | | |
|
| |\|
| |
| |
| |
| | |
Tidy up the ChannelSender::poll_ready inherent method
See merge request tpo/core/arti!2171
|
| | |
| |
| |
| | |
This is where it belongs.
|
| | |
| |
| |
| |
| |
| |
| | |
This makes this available for any Sink + Unpin. Which we want because
we're about to wrap our ChannelSender in a Sink wrapper.
It's in the wrong place now; we'll move it in a moment.
|