mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.4.0 2026-05-07T15:05:57Z 2026-05-07T15:05:57Z Steven Engler opara@torproject.org 2026-05-06T23:05:12Z urn:sha1:89790050b66f4eed80b9215b18c893ab7adba298 This adds the trait type `ListenOptions` to `NetStreamProvider` and adds this `ListenOptions` as an argument to `NetStreamProvider::listen()`. You probably want to look at the changes in tor-rtcompat first, then the rest of this commit is updating the various places we use `NetStreamProvider`. 2026-02-16T15:22:24Z Gabriela Moldovan gabi@torproject.org 2026-02-16T14:37:30Z urn:sha1:47764231d9cf38b549f60490cf8b991832aed35f 2025-11-06T11:28:22Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-11-06T11:23:25Z urn:sha1:a5fd5c48ea059a80cc1f6c50e248654b5ff3aaff Run maint/add_warning 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-09T11:45:54Z urn:sha1:6b9a51a08dea8b987a017c1abbf87ba6bcb54d88 2024-12-10T10:34:48Z Gabriela Moldovan gabi@torproject.org 2024-12-05T15:02:12Z urn:sha1:bf7f5c8ea91357be2b2be366a91bee3d17ac5ecb Part of #1769 2024-09-24T13:10:11Z Nick Mathewson nickm@torproject.org 2024-09-19T12:13:29Z urn:sha1:07ca20d4aaa7081bd901cc487fbb093bf05f5a76 Stop referring to TCP streams in its documentation; update other documentation to refer to NetStreamProvider rather than TcpProvider. 2024-09-24T13:10:11Z Nick Mathewson nickm@torproject.org 2024-09-19T11:55:22Z urn:sha1:8c2d84000e4d5ba74e7b6b4e9dac3fc700f618b5 (And similarly rename TcpListener to NetStreamListener, along with their TcpStream/TcpListener associated types.) These types are about to become generic over addresses, and therefore shouldn't be named after TCP. Renaming was done mostly with Rust Analyzer, except for some macros that needed to be hand-edited. (I'll revise the comments in the next commit; this one is all about renaming.) 2024-09-24T13:10:11Z Nick Mathewson nickm@torproject.org 2024-09-18T22:57:09Z urn:sha1:168f55df05f4b56fd61423c020ce62e93f1d7a9f It's redundant with the incoming() method (which turns the TcpListener into a Stream of connections), and nothing actually used it outside of tests. Removing this method allows us to simplify our TcpListener code a good deal, as can be seen by some of the implementations we removed from our example and testing code. 2024-09-24T13:10:11Z Nick Mathewson nickm@torproject.org 2024-09-18T20:43:50Z urn:sha1:0121822457f77b9d669c38194919b5bfd908b9a1 With this extension trait, we no longer need to construct `CompoundRuntime` directly outside of tor-rtcompat. This in turn will make it a little less painful when we have to add more generics to CompoundRuntime.