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

memquota: Use _ rather than allow(dead_code) (fmt)

2024-10-22T12:19:22Z

memquota: Use _ rather than allow(dead_code)

2024-10-22T12:19:22Z

Promote the associated comments. As suggested here: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2560#note_3097188

memquota: fix data stream account lifetime

2024-10-21T10:11:20Z

The DataStream is sometimes disassembled, eg by split. When that happens, the StreamAccount would be dropped - and that was the only strong reference. Put a StreamAccount in each of the pieces, instead of just in the combined DataStream struct.

memquota: Fix resolve stream account lifetime

2024-10-21T10:11:20Z

We need the mq account for the stream not to collapse. The ResolveStream object needs to contain a strong reference to it. Have begin_stream_impl return the StreamAccount, rather than taking it as a parameter. That makes this bug a little more obvious. It also centralises the StreamAccount creation.

tor-proto: Put a StreamAccount in DataStream etc.

2024-10-03T14:10:47Z

tor-proto: Put a StreamAccount in DataStream etc. (pre-fmt)

2024-10-03T14:10:47Z

Some HasMemoryCost impls in tor-proto

2024-10-02T18:11:26Z

tor-proto: Introduce type aliases for stream queues

2024-10-02T14:15:56Z

This will make it easier to change their types.

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.

flow-control: document idea for making more robust

2024-08-21T21:53:08Z

From