| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets us avoid calling `Instant::now()`, when `Runtime::now()`
is what we want.
Unfortunately, there are a bunch of functions that called `update()`
that needed to change. Fortunately, none of the changes were very
complicated.
Fixes a `TODO pt-client` comment.
|
| |
|
|
| |
descriptors updated as appropriate.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
These arguments were used only for legacy (testing) purposes; the
tests now use `TestNetDirProvider`. This lets us simplify our
internal logic for passing a `NetDir` to our samples, and prepare
for having a `BridgeSet` to pass there instead.
This is a breaking change to `guardmgr` and `circmgr`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously it was the job of a task in CircMgr to do this; but we're
going to want to give GuardMgr full access to the latest NetDir for
this, and for other code-simplification reasons.
With this change I'm deprecating a couple of functions in
tor-circmgr. It's no longer necessary for us to have an artificial
external way for you to feed new NetDirs to a circmgr. (I could
just remove them, but I want practice deprecating.)
|
| |
|
|
| |
(It is not yet actually used.)
|
| |
|
|
| |
(The information is not yet recorded.)
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Instead of putting a fully qualified name in the text, in most cases
we should just use the short name of the type or function we're
referring to.
In other words, instead of saying [`crate::module::Foo`], we should
typically say [`Foo`](crate::module::Foo).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The advantage here is that we no longer have to use a futures-aware
Mutex, or a blocking send operation, and therefore can simplify a
bunch of the GuardMgr APIs to no longer be async. That'll avoid
having to propagate the asyncness up the stack.
The disadvantage is that unbounded channels are just that: nothing
in the channel prevents us from overfilling it. Fortunately, the
process that consumes from the channel shouldn't block much, and
the channel only gets filled when we're planning a circuit path.
|
| |
|
|
|
|
|
| |
Also, refactor our message handling to be more like the tor_proto
reactors. The previous code had a bug where, once the stream of
events was exhausted, we wouldn't actually get any more
notifications.
|
|
|
There are some missing parts here (like persistence and tests)
and some incorrect parts (I am 90% sure that the "exploratory
circuit" flag is bogus). Also it is not integrated with the circuit
manager code.
|
