mirrors/arti.git/crates/tor-proto/src/stream/queue.rs, branch mainmirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=main2026-05-21T00:36:59Ztor-proto: small comment improvements2026-05-21T00:36:59ZSteven Engleropara@torproject.org2026-05-13T04:17:19Zurn:sha1:0a5f5c97c67e868a8a01e5639e570fa8b2cfd88btor-proto: remove unneeded type alias2026-05-21T00:36:59ZSteven Engleropara@torproject.org2026-05-13T04:30:22Zurn:sha1:b7769c1500fb1806e7a962a36fb0c03203f2bc1ctor-proto: always use a bounded mpsc queue for streams2026-05-21T00:36:59ZSteven Engleropara@torproject.org2026-05-13T04:06:28Zurn:sha1:4a3a9b0145c180519a298426f5bf8d4e3b2d51bd
Whether a stream queue should be bounded or unbounded is a decision that
needs to be made at runtime depending on the type of flow control used,
not at build-time. Window-based flow control should be bounded and
XON/XOFF flow control should be unbounded.
If we wanted to support both bounded and unbounded queues, it would take
a bunch of boilerplate code to wrap the senders and receivers in enums.
Instead we make the queue always bounded, but use a large bound for
XON/XOFF flow control.
Fix typos2026-03-24T16:04:08ZTobias Stoeckmanntobias@stoeckmann.org2026-03-24T16:04:08Zurn:sha1:1fb2b8dd4aee7c943ce90d6631be473f2a296fe6
Typos found with codespell
proto: Adjust docs to refer to the new location of StreamReceiver2025-11-24T17:03:48ZGabriela Moldovangabi@torproject.org2025-11-20T12:09:37Zurn:sha1:cfe5aab60eac9bbc678bef4742f6281d3c08447a
While we still re-export StreamReceiver from the client module, I want
to avoid importing it from there in the implementation-agnostic modules,
just to make it clearer we're not using client-specific types.
proto: Move dumb pipes to top-lvl stream module2025-10-21T17:08:13ZGabriela Moldovangabi@torproject.org2025-10-21T17:08:13Zurn:sha1:86a5d8ee712a57955f5256ac5af2c2f044a43a61proto: Move the `stream` module under `client` (breaking).2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:52:38Zurn:sha1:702e7276898d3f31e22033c5b64fea91703f3701
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
Switch Cargo.toml files to edition 2024.2025-08-07T15:28:36ZNick Mathewsonnickm@torproject.org2025-08-06T01:19:58Zurn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
tor-proto: make stream recv queues unbounded if "flowctl-cc" enabled2025-08-05T20:01:23ZSteven Engleropara@torproject.org2025-07-31T19:59:02Zurn:sha1:441a496521f3d823be11c8aaa7e32ebf959e8ff0tor-proto: add `DataReaderNew`2025-07-17T18:02:07ZSteven Engleropara@torproject.org2025-07-17T06:59:32Zurn:sha1:14d95aee7878ce28cb7f8af539b2bca287e785fc
This will later become `DataReader`.