mirrors/arti.git/crates/tor-rtcompat/src/general.rs, branch arti-v2.1.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.1.02025-11-24T16:28:07Zopentelemetry: Instrument a bunch of functions.2025-11-24T16:28:07ZWesley Aptekar-Casselsme@wesleyac.com2025-11-24T16:28:07Zurn:sha1:a4db6a7495b13dd7b00416dd1660a5ad82b60919
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
Switch Cargo.toml files to edition 2024.2025-08-07T15:28:36ZNick Mathewsonnickm@torproject.org2025-08-06T01:19:58Zurn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
tor-rtcompat: Add the ability to get a StreamOps handle.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T11:06:59Zurn: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
rtcompat: re-export items from tor_general_addr::general2024-12-19T21:12:25ZNick Mathewsonnickm@torproject.org2024-12-11T19:41:25Zurn:sha1:61a8ec6f61caa6a1fa4ead15384d9a81553b1192tor-rtcompat: Require NetStream{Listener,Provider} streams to impl StreamOps.2024-12-10T10:34:48ZGabriela Moldovangabi@torproject.org2024-12-05T15:02:12Zurn:sha1:bf7f5c8ea91357be2b2be366a91bee3d17ac5ecb
Part of #1769
tor-rtcompat: Implement StreamOps for all the stream types.2024-12-10T10:34:48ZGabriela Moldovangabi@torproject.org2024-12-05T15:00:11Zurn:sha1:56e9b79b09c65caee25a50c083fdd40f8c66f040
Part of #1769
Remove re-export of "general::*" from tor-rtcompat.2024-10-29T17:42:36ZNick Mathewsonnickm@torproject.org2024-10-29T17:42:36Zurn:sha1:6239b036dcb041f6c7371fee824c3d65ec6f7d06Remove re-export of "unix" from tor_rtcompat.2024-10-29T17:36:16ZNick Mathewsonnickm@torproject.org2024-10-29T17:36:16Zurn:sha1:7ddd8bacdfbd91356805a37e15c023e3b525b6e8Extract general::SocketAddr and its unix friends to their own crate.2024-10-29T17:25:48ZNick Mathewsonnickm@torproject.org2024-10-29T17:22:05Zurn:sha1:14694f1de79c2eaaf6dd7a3ea781ccb757467378
This is mostly code motion.
general::SocketAddr: Say "inet" rather than "tcp"2024-10-17T18:07:03ZNick Mathewsonnickm@torproject.org2024-10-17T18:07:03Zurn:sha1:ca0ec6d8f999a9f474f7d4dffa49f509fafcda77
"inet" makes more sense, since in principle these can also be used
for udp, etc.
Also making a corresponding change in rpc-connect-sketch.md,
which uses this format.
Closes #1701.