mirrors/arti.git/tor-rtcompat/src/impls.rs, branch arti-v0.0.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.02021-03-23T19:59:39ZMove responsibility for knowing about TLS into tor_rtcompat.2021-03-23T19:59:39ZNick Mathewsonnickm@torproject.org2021-03-23T19:59:39Zurn:sha1:d073f24138261bb44fd70a4ffb9e8da12185fee5
Now we don't need runtime-specific stuff in tor-chanmgr.
Port to work with tokio or async-std.2021-03-02T16:55:09ZNick Mathewsonnickm@torproject.org2021-03-01T21:14:43Zurn:sha1:8c314185002d520f0869ea3bd0fc35736b103f98
This is fairly ugly and I think I'll need to mess around with the
feature configuration a while until we get something that's pleasant
to develop with. This still seems like a good idea, though, since
we _will_ need to be executor-agnostic in the end, or we'll have no
way to handle wasm or embedded environments.
Later down the road, we'll probably want to use futures::Executor or
futures::Spawn more than having global entry points in
tor_rtcompat. That would probably make our feature story simpler.
Tokio is the default now, since tokio seems to be more heavily used
for performance-critical stuff.
This patch breaks tests; the next one will fix them, albeit
questionably.
Require documentation in tor-rtcompat.2020-11-20T22:24:16ZNick Mathewsonnickm@torproject.org2020-11-20T22:24:16Zurn:sha1:3d4f5f261e78e482a3a849c109c2b2e354751914Isolate async_std usage in a new tor_rtcompat crate.2020-11-11T18:46:39ZNick Mathewsonnickm@torproject.org2020-11-11T18:46:39Zurn:sha1:59e4b5631a9b9f8c9c43ba579bf43a17ac64d541
Like tor_llcrypto, this crate is meant to expose only the part of
other crates (in this case, a async runtime crate) that we use.