mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=main 2025-01-15T13:49:17Z 2025-01-15T13:49:17Z Gabriela Moldovan gabi@torproject.org 2025-01-08T11:06:59Z urn:sha1:267235969df65d975b5deb01c342e1073d4c3847 Needed for cases where we wrap an object that implements `StreamOps` in an external type, thereby losing access to the `StreamOps` functionality. For example, during the channel handshake, we `.split()` the stream that implements `StreamOps`, which leaves us with a `SplitSink` and a `SplitStream`, neither of which implement `StreamOps`. Getting a handle to the underlying object that implements `StreamOps` (for example, a file handle) *before* the stream is `.split()` enables us to use `StreamOps` to manipulate the underlying split stream. This commit also introduces a special `UnsupportedStreamOpsHandle`, which is a type that implements `StreamOps`, but always returns an error. This type is meant to simplify error handling and usage, and is meant to be used in cases where `StreamOps` is not supported. TODO: the name of this type is pretty confusing (it's very similar to `UnsupportedStreamOp`, which is an error type), and should probably be renamed to something else (`NoOpStreamOpsHandle`, `BrokenStreamOpsHandle`, `DummyStreamOpsHandle` come to mind...). Note: this changes the `StreamOps` trait to be slightly different from what I originally envisioned in !2660 and #1769 2024-12-10T10:34:48Z Gabriela Moldovan gabi@torproject.org 2024-12-05T15:00:11Z urn:sha1:56e9b79b09c65caee25a50c083fdd40f8c66f040 Part of #1769 2024-09-24T13:10:11Z Nick Mathewson nickm@torproject.org 2024-09-23T17:20:47Z urn:sha1:014ea0c7512d2199d8b5b98c75e38fba4938afda It turns out that these types are generally useful, and that they are in fact needed for tor-rtmock to compile without a PreferredRuntime.