| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
It's useful to know now only if we now have the lock, but also if we
just got it for the first time.
|
| | |
| |
| |
| |
| | |
We can use this in the case where we don't get the lock on the
state file, because another process is running.
|
| |/
|
|
| |
(One represents code that I forgot to write.)
|
| |
|
|
|
|
|
|
|
| |
The `get_relay` function was confusing, since it would return None if
the relay was present, but wasn't actually a guard. We only used it
in one place, and in that one place we used it wrong, leading to a
panic bug.
Fixes #193.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code would report all failures to build a circuit as
failures of the guard. But of course that's not right: If we
fail to extend to the second or third hop, that might or might not
be the guard's fault.
Now we use the "pending status" feature of the GuardMonitor type so
that an early failure is attributed to the guard, but a later
failure is attributed as "Indeterminate". Only a complete circuit
is called a success. We use a new "GuardStatusHandle" type here so
that we can report the status early if there is a timeout.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
By the time I merge this, most of the comments should have tickets
to go with them.
|
| |
|
|
|
|
|
| |
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.
|
