mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.5 2025-06-26T17:33:36Z 2025-06-26T17:33:36Z Steven Engler opara@torproject.org 2025-06-26T17:33:36Z urn:sha1:c4f15fab9a79bfb12b71e06a2e2ac0eb7af16766 2025-06-26T17:03:13Z Steven Engler opara@torproject.org 2025-06-26T04:52:17Z urn:sha1:71e10a6155b533436befb205661fe98b83fab9e6 Now that we no longer need to store a future, there's no need for this state since we're never pending waiting for a future to complete. 2025-06-26T17:03:13Z Steven Engler opara@torproject.org 2025-06-26T04:45:27Z urn:sha1:3eabc89dc9a1f6be166c2a468785d7708aa3a5bb Having this be a `futures::Stream` makes it nicer to work with. For example we are able to remove a boxed future from `DataReaderState`, which should be better for performance and makes the code simpler. As mentioned in a previous commit when this type was named `StreamReader`, this type is public in the API, but is not actually accessible. As far as I can tell there is no way to construct it or access it. 2025-06-26T17:03:08Z Steven Engler opara@torproject.org 2025-06-26T04:02:53Z urn:sha1:eed047cbf888dc8f2d02c772e4b9a5154c77a3d4 There are some pros/cons to this change: Pros: 1. The only remaining `await` in `StreamReceiver::recv` is for polling the receiver, which means we can turn the `StreamReceiver` into a `Stream` in a future commit. 2. We won't block the user from receiving messages while we wait for the circuit reactor to receive our SENDME message and send it on the outgoing channel. 3. The `StreamReceiver` doesn't really care if it can't send the SENDME. There isn't anything it can do, the circuit hop can go away for external reasons like a DESTROY message, and we still want to return all queued messages to the user anyways. Cons: 1. If the `StreamReceiver` sends a SENDME request to the circuit reactor, and the circuit reactor fails to send the SENDME, there's no good way for the reactor to communicate this back to the `StreamReceiver`. 2025-06-26T17:01:22Z Steven Engler opara@torproject.org 2025-06-26T03:20:38Z urn:sha1:d633fbc26e84b190306998833f5c8a1e10b58e50 In rust, the typical nomenclature is to use "receiver" for channels, and "reader" for byte streams. For example `mpsc::Receiver` for something that returns objects and `AsyncRead` for something that reads bytes. Since we also have a `DataReader` for reading bytes, I think renaming this from `StreamReader` to `StreamReceiver` better describes what it is (it's not a "reader" in the typical `Read`/`AsyncRead` sense). This type is public in the API, but is not actually accessible. As far as I can tell there is no way to construct it or access it. 2025-06-16T19:19:37Z Steven Engler opara@torproject.org 2025-06-09T16:46:37Z urn:sha1:993486444b83d9be21a046a9c04a1efe90a55f3a This uses just a placeholder `Empty` stream for config updates. 2025-06-16T19:19:37Z Steven Engler opara@torproject.org 2025-06-09T16:42:12Z urn:sha1:14b49bfd2f037728d7f02994abb986f0e4301515 We want the tokio trait to call into the futures trait, rather than having each trait duplicate the logic of calling into the inner writer. This is less error-prone. 2025-06-08T23:24:31Z Steven Engler opara@torproject.org 2025-06-08T21:42:29Z urn:sha1:9779de7adbe4aa9cc848e685151a6c5cde0a7bce 2025-06-05T15:27:43Z Steven Engler opara@torproject.org 2025-06-04T21:23:24Z urn:sha1:71deeccda0f8f253651516bc480861c48e90eab3 The user now sets a constant amount of bytes to wait for. 2025-06-05T15:14:50Z Steven Engler opara@torproject.org 2025-06-04T18:51:21Z urn:sha1:03c5c523039a03fe2b479fc9e7f2841440eb529b