mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.5.0 2026-05-21T16:35:59Z 2026-05-21T16:35:59Z Steven Engler opara@torproject.org 2026-05-21T15:13:07Z urn:sha1:3ae295c879f773b8c6e922436fb96c020777555a 2026-05-21T16:35:59Z Steven Engler opara@torproject.org 2026-05-21T02:13:21Z urn:sha1:73088207825942721ec02ccec4d2424e688586f3 This better matches nearby code. 2026-05-21T16:35:59Z Steven Engler opara@torproject.org 2026-05-21T02:56:49Z urn:sha1:6a9e07f8d42ebd6f698b0def041c5424cf2d42b8 2026-05-21T16:35:59Z Steven Engler opara@torproject.org 2026-05-21T01:57:13Z urn:sha1:e62d824614fc501d21f6b58f1e98346bf495e1e3 Previously when initializing a stream, we constructed most of the stream-related queues outside of the reactor and passed the relevant halves of the queues (senders or receivers) into the reactor. A downside of the above approach is that the reactor may be better informed about what queues to construct, and how to construct them. For example the reactor knows what type of flow control that the hop is using, so it knows whether we need queues for passing rate limits and drain rates for XON/XOFF flow control. This commit moves the construction of these queues into the reactor and passes the relevant halves out of the reactor. In the future we can make better decisions about which queues are needed depending on the flow control method used instead of always constructing them (see arti#2068). Reviewing with `--color-moved` might be helpful as a few lines have been moved. 2026-05-21T01:52:49Z Steven Engler opara@torproject.org 2026-05-20T19:29:58Z urn:sha1:2801a1b30f50488ca79bbe21d3061b07fe40b945 2026-05-21T00:36:59Z Steven Engler opara@torproject.org 2026-05-13T04:06:28Z urn: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. 2026-05-21T00:36:59Z Steven Engler opara@torproject.org 2026-05-12T22:36:57Z urn:sha1:be505ab176da88dd8cea7e3a42530d81fb0267b5 The stream queue length (for messages incoming from the Tor network) depends on the type of flow control we're using for the hop. Currently we construct the stream queue outside of the circuit reactor, but we don't have the flow control information here. Instead of constructing the stream queue outside of the reactor and passing the sender into the reactor, we construct the stream queue inside of the reactor and pass the receiver out of the reactor. 2026-05-21T00:36:59Z Steven Engler opara@torproject.org 2026-05-12T15:48:58Z urn:sha1:f0f6fcbc3d694d008e8b9708e1e9841700715f57 2026-05-07T14:31:50Z Steven Engler opara@torproject.org 2026-04-30T18:05:48Z urn:sha1:2ac2a4764b605f76684ed87f87c0b2f80229e4cd This moves the window-based flow control for half-streams out of the `HalfStream` and into the `HalfStreamWindowFlowCtrl` object. Now that it's applied only in `HalfStreamWindowFlowCtrl` and not generally for all half-streams, we no longer apply window-based flow control to half-streams when they're really using xon/xoff-based flow control. 2026-03-30T03:00:32Z Steven Engler opara@torproject.org 2026-03-30T02:50:26Z urn:sha1:37471115785d4d428c6d2b17c434307b42bce998 Previously we would close the circuit, which isn't great because there can be other streams in use on the circuit.