mirrors/arti.git/crates/tor-proto/src, branch arti-v1.2.7

Fix typos

2024-09-03T08:09:02Z

Move stream_peek into tor-async-utils

2024-08-29T14:08:06Z

extract tor_async_utils::oneshot into ::oneshot-fused-workaround

2024-08-28T14:27:46Z

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.

`tor_proto::channel`: update comment to point to `tor-chanmgr`

2024-08-27T14:33:11Z

`circuit` docs: delete comment about no flow-control etc

2024-08-26T19:53:11Z

There is now (sendme-style) flow control, and some fairness (via round robin scheduling of streams).

`circuit` docs: delete "one big mutex" limitation

2024-08-26T19:36:01Z

There is a mutex for some of the "mutable state", but the reactor only needs to lock it when adding a hop. It's not needed "to process a cell" or when streams send. Probably not worth calling out here.

tor-proto circuit: add unit test for fairness

2024-08-22T18:51:03Z

flow-control: document idea for making more robust

2024-08-21T21:53:08Z

From

Circuit reactor: improve code comments

2024-08-21T21:53:08Z

In particular, clarify that stream-flow-control msgs don't get blocked on circuit congestion control.

StreamPollSet: disallow polling ready streams

2024-08-21T18:30:55Z