mirrors/arti.git/crates/tor-circmgr/src/build.rs, branch arti-v0.0.3

Merge branch 'remove-type-annotation' into 'main'

2022-01-07T19:33:04Z

tor-circmgr: Remove a type annotation in a method call See merge request tpo/core/arti!225

tor-circmgr: Remove a type annotation in a method call

2022-01-07T18:12:27Z

This is a method, so the resolution is automatic. It's not clear to me why this was written out this way, given that extend_ntor is right above. Signed-off-by: Ian Jackson

De-Arc-ify Buildable for ClientCirc

2022-01-06T20:22:49Z

Merge branch 'main' into 'remove_unused_rngs'

2022-01-06T15:48:42Z

# Conflicts: # crates/tor-circmgr/src/build.rs

Remove a bunch of unused RNGs

2021-12-26T02:44:55Z

tor-circmgr: Don't clone parameters in create_chantarget()

2021-12-26T01:22:38Z

Allow on-the-fly changing of path_rules

2021-12-07T20:42:14Z

And now the complexity begins: when the user changes the path_rules, they not only want new circuits to obey those rules: they want _all new requests_ to be put onto circuits that obey those rules. That means that when the path rules become more restrictive, we need to retire all the circuits, and make sure that currently pending circuits aren't used for any requests. If it's any comfort, doing this was even more complicated in C tor. ;)

Sketch API for reconfiguration.

2021-12-07T20:42:14Z

This patch doesn't actually make anything reconfigurable, but it does create an API that will tell you "you can't change the value of that!" If the API looks reasonable, I can start making it possible to change the values of individual items.

add semicolons if nothing returned

2021-11-25T13:20:37Z

Completely overhaul the tor-proto circuit reactor

2021-11-12T15:04:24Z

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.