| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rather like e8e9699c3c239d6c30f9ad414f15d3bad6ec03fd ("Get rid of
tor-proto's ChannelImpl, and use the reactor more instead"), this
admittedly rather large commit refactors the way circuits in `tor-proto`
work, centralising all of the logic in one large nonblocking reactor
which other things send messages into and out of, instead of having a
bunch of `-Impl` types that are protected by mutexes.
Congestion control becomes a lot simpler with this refactor, since the
reactor can manage both stream- and circuit-level congestion control
unilaterally without having to share this information with consumers,
meaning we can get rid of some locks.
The way streams work also changes, in order to facilitate better
handling of backpressure / fairness between streams: each stream now has
a set of channels to send and receive messages over, instead of sending
relay cells directly onto the channel (now, the reactor pulls messages
off each stream in each map, and tries to avoid doing so if it won't be
able to forward them yet).
Additionally, a lot of "close this circuit / stream" messages aren't
required any more, since that state is simply indicated by one end of a
channel going away. This should make cleanup a lot less brittle.
Getting all of this to work involved writing a fair deal of intricate
nonblocking code in Reactor::run_once that tries very hard to be mindful
of making backpressure work correctly (and congestion control); the old
code could get away with having tasks .await on things, but the new
reactor can't really do this (as it'd lock the reactor up), so has to do
everything in a nonblocking manner.
|
| |\ \
| | |
| | |
| | |
| | | |
Fix typos
See merge request tpo/core/arti!127
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It requires tracing-subscriber 0.2, which is a lower version than we
want, and which causes trouble with our minimal-versions CI test.
There is a pending issue to fix this; we can reinstate tracing-test
once it is merged: https://github.com/dbrgn/tracing-test/pull/11
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
It seems like a good time to do this, before we add a zillion other
arguments to begin_stream.
|
| | |
| |
| |
| |
| |
| |
| | |
* Make it crate-visible only.
* Make it idempotent
* Have it be an internal error if it's called at the wrong time.
* Simplify the return logic.
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Previously we didn't check for the space.
Closes #225.
|
| | | | |
|
| |/ / |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
It formats them in a nice little json object, which it writes to
stdout.
Part of arti#172
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Format checks seem to be the fastest operation, and tests are the
slowest. Reordering Git hook tasks from swiftest to slowest should
provide quicker automated feedback when committing and/or pushing.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
> Check the Read Me file for Cargo Husky crate for details
>
> https://github.com/rhysd/cargo-husky#readme
These changes allow for local `git commit` and `git push` related hooks to more
closely match remote CI/CD operations. Most notably the `cargo clippy...` lint
command from ".gitlab-ci.yml" file now may guard against committing/pushing
code that would otherwise cause CI/CD pipeline failures.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Tune the 'profile.release' options for a smaller compile size.
See merge request tpo/core/arti!124
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
By enabling link-time optimization, setting 'opt-level=s', and
setting compilation-units=1, we can get a much smaller download
size, which is one of our objectives.
Making these changes reduces the binary size for me (on x86_64) by about
42%. If you also run "strip --strip-debug" on the resulting binary,
the resulting size is 55% smaller than the original binary size.
These effects persist if you compress the binary. Supposing that we
use xz compression, these options make save 32% of compressed binary
size. If we also "strip --strip-debug" before compressing, the compressed
binary saves 43% from the original binary size.
With all of these options applied, on x86_64 linux with xz
compression, we're at a nice 1.5 MiB download. If we statically link
to openssl and sqlite, we're still only at a 2.8 MiB download.
There is a build time cost to these changes: for me, it comes to
a 10%-25% build time increase.
This is part of arti#172.
|
| | | | | |
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | | |
These test our download schedules, resetting to the original state,
and storing downloaded objects.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In rust-nightly CI, forbid debugging prints.
Closes #218
See merge request tpo/core/arti!123
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch makes the rust-nightly CI task fail if it detects any
dbg!(), println!(), or eprintln!() calls in production code.
Because of clippy limitations, it may also gripe about calls to
these macros in our tests. The preferred workarounds are to either
instead. Both are acceptable.
We're doing this check in CI rather than unconditionally with clippy
directives, since we often want to have these calls in our code
temporarily while we're developing. Some day we might want this
test to go into a pre-push hook.
This patch also adds #![allow()] directives for println!() and
eprintln!() in the arti crate. Since that one isn't a library, it's
okay for it to speak to stdout/stderr.
Closes #218.
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We need this for clock_gettime_nsec_np().
The source is not canonical, but neither was the one we were using
before. To mitigate this, I've added a digest check on the SDK after
downloading it.
A 100% real canonical reproducible build process will probably
require Apple hardware anyway.
Closes #221
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | | |
Also add a comment about a possible problem behavior in read-only
estimators.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Previously it was either all-locked or all-not-locked. Now you can
simulate having the same shared storage opened by multiple managers,
only one of which has the lock.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
@nickm pointed out that refactoring tor_proto::channel's Reactor to do
sending as well meant that it could only send or receive, but not both,
simultaneously, which was bad!
To fix this, rewrite Reactor::run_once to use a handcrafted future (with
futures::future::poll_fn) that can handle the logic required to push
items onto the sink asynchronously (i.e. checking that it can be written
to before trying to do that, and then flushing it).
This also means we don't use select_biased! any more, and just handroll
that logic ourselves; as a small bonus, we can now process all 3 kinds
of message in one run_once() call, instead of having to do only one of
them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead of awkwardly sharing the internals of a `tor-proto` `Channel`
between the reactor task and any other tasks, move most of the internals
into the reactor and have other tasks communicate with the reactor via
message-passing to allocate circuits and send cells.
This makes a lot of things simple, and has convenient properties like
not needing to wrap the `Channel` in an `Arc` (though some places in the
code still do this for now).
A lot of test code required tweaking in order to deal with the refactor;
in fact, fixing the tests probably took longer than writing the mainline
code (!). Importantly, we now use `tokio`'s `tokio::test` annotation
instead of `async_test`, so that we can run things in the background
(which is required to have reactors running for the circuit tests).
This is an instance of #205, and also kind of #217.
|
| | | |
| | |
| | |
| | |
| | | |
This check relies on families being enforced correctly, which is not
the case when specifying a fixed exit and using guards. (See #183)
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is based on @eta's patches for !118 and !119: Since we already
have an unbounded channel, we don't need to use an elaborate mess of
one-shot senders. We can just use the unbounded_send() method,
which also lets us enqueue a message without having to await.
Closes #219.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This doesn't add much to coverage, but it's important.
|
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We define "coming back online" as happening when a guard attempt
succeeds, if that attempt that was launched when we seemed to be
offline.
We define "seeming to be offline" as having all of our primary
guards marked unreachable, and having received no incoming network
traffic in a while.
Closes #216.
|
