| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | | |
This is going to get more complicated.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We're going to want to do more complex things here.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use the standard multiplicity technique rather than the ad-hoc impl on
Option. This allows us to support an ad-hoc parsing function for a
field that's `Option`.
Disentangle the `label` field attribute, which did both setting the
label, and expecting a different parsing approach: replace it with
`with`.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This mistake escaped because this wasn't actually checked by the code,
but it's going to be checked in a moment.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The previous code didn't compile at all, and this went unnoticed
because it wasn't used by the poc.
|
| | | | |
| | | |
| | | |
| | | | |
Without this, parsing of Option and Vec argument fields doesn't work.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This macro has some problems which I'm going to fix. Add a test case
for the parts that are currently working.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
`problem` is the `#[source]`.
|
| | | | |
| | | |
| | | |
| | | | |
`#[from]` is not `#[source]`. We need to print the inner error.
|
| | | | |
| | | |
| | | |
| | | | |
Worsify formatting as demanded by rustdoc.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Otherwise it's easy to get confuseed by ---- dividers for Objects.
|
| | | | |
| | | |
| | | |
| | | | |
For reasons, TestResult doesn't print error sources.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is needed when using these macros in a namespace with a local
redefinition of `Result`.
|
| | | | |
| | | |
| | | |
| | | | |
I triggered this error and it didn't work right.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Also derives `CIRC_ACTION_COUNT` from the two other constants instead of
hard-coding the value.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Besides, it's better if we use the same number for the expected number
of legs as we do in the conflux set impl.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This rewrites `next_circ_action()` yet again, using two layers of
`PollAll`:
* the inner layer drives an individual circuit leg. Each circuit
has a `PollAll` that drives its futures
* the outer layer drives the inner `PollAll`s belonging to the
circuits that form the tunnel
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We don't really need to return a `HopNum` anymore (because we work out
the join point `HopNum` unconditionally in `next_circ_action`).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we poll the ready streams on the join point more than once per
reactor loop, we risk sending more than one DATA cell (which is not
good, because cc might block after the first cell is sent).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This removes our usage of `FuturesUnordered` in
`ConfluxSet::next_circ_action()` to address two issues:
* a fairness issue, where the futures driven by `FuturesUnordered`
could be starved under some circumstances (#2180)
* a logic error, where we'd explicitly avoid reading from the input
channel if the outgoing `chan_sender` channel was blocked (#2179)
Note that the fixing the latter will cause the reactor to buffer more
into the unbounded `chan_sender` sink, but that *should* be okay,
because no input message should be able cause us to queue cells
excessively.
Closes #2179, #2180
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We will soon need to access this directly (rather than via a method on
`Circuit`) to work around borrow checker limitations.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Part of #2180
Note: the code is intentionaly left misindented to make reviewing a
bit easier. A future commit will fix the indentation.
|
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
This simplifies the calling code, which will, in turn, make it easier
for us to simplify the logic in ConfluxSet::next_circ_action() and
abolish the questionable use of FuturesUnordered.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
proto: Remove half-streams when they expire.
Closes #264
See merge request tpo/core/arti!3267
|
| | | | |
| | | |
| | | |
| | | | |
I want to tackle this separately, as part of #2003
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3267#note_3261239
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3267#note_3259820
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Half-streams are periodically removed from each hop's stream map by the
reactor main loop, but we still need to ensure we reject any messages
arriving on expired half-streams in between these cleanup cycles.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This tests that the half-stream expiry works as expected.
Note: it doesn't! This test currently fails, because there's a bug in
the way half-streams are expired. Because we don't do it on a timer, and
instead garbage-collect the half-streams on each reactor iteration, if
the reactor is stuck long enough `.await`ing a message on one of its
channels (for example, the `input` one), there is a chance it will
accept a cell on a half-stream that should've been expired.
A future commit will fix this bug.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This should look at length of the circuit up until the hop where the
half-stream is (because the half-stream might be on an intermediate hop,
and not necessarily on the final one).
|