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

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.

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

proto: Try to clarify why StreamReader has a StreamTarget.

2024-05-29T11:28:05Z

proto: Improve documentation about DataStream lifetimes and closing

2024-05-29T11:28:05Z

In particular, clarify that dropping the DataWriter on its own does nothing unless the DataReader is also dropped. Related to #1368.

proto: Make DataWriter::close actually do something.

2024-05-29T11:28:01Z

Previously we had a bug where `::close` (or `shutdown` in tokio-land) would not actually have any effect. It _would_ drop the `StreamTarget` held by the `DataWriter`, but since the `DataReader` also held a `StreamTarget`, the MPSC channel would not get closed, and the circuit reactor would not realize that the stream wanted to shut down. Now we use `mpsc::Sender::close_channel` to make our closes effectual. Closes #1368. Additionally, we fix a bug where `poll_close()` never actually did anything if the buffer had nothing in it when it was called. Previously, `poll_flush_impl()` would exit immediately if it had no data to flush. That isn't what we want when we are closing!

proto: Fix compilation with stream-ctrl but not experimental-api.

2024-05-14T12:04:03Z

proto: Expose wait_for_connection as a part of the DataStream API.

2024-05-09T20:34:17Z

Rename UnparsedRelayCell -> UnparsedRelayMsg

2024-03-12T15:58:12Z

For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253