summaryrefslogtreecommitdiff
path: root/tor-rtcompat/src/impls
Commit message (Collapse)AuthorAgeFilesLines
* Implement Runtime for a thin wrapper around tokio runtime handlesNick Mathewson2021-05-201-38/+96
| | | | | Having this enables us to use Arti with an externally constructed tokio runtime.
* Try to avoid a tor-rtcompat publicness warningNick Mathewson2021-05-181-0/+1
|
* Add the "unreachable_pub" lint.Nick Mathewson2021-05-181-1/+0
| | | | | | This is a somewhat obnoxious change in its scope and requirements, but it makes it easier to understand what the real public and private parts of our APIs are.
* tor-rtcompat: Add missing documentation for async_std.rsNick Mathewson2021-05-071-1/+22
|
* Remove most pin_project usage in tor_rtcompat.Nick Mathewson2021-04-282-40/+20
|
* cargo fix --edition-idiomsNick Mathewson2021-04-261-1/+1
|
* rtcompat: remove an unused conversion function.Nick Mathewson2021-04-191-5/+0
|
* Clarify what TlsConnector doesn't validate.Nick Mathewson2021-04-192-4/+8
|
* Flatten async_std impl module slightly.Nick Mathewson2021-04-191-31/+30
|
* Flatten tokio TcpProvider implementation a bit.Nick Mathewson2021-04-191-64/+35
|
* Add a local_addr() function for TcpListener.Nick Mathewson2021-04-182-1/+9
|
* tor_rtcompat: Documentation and cleanupsNick Mathewson2021-04-172-33/+10
|
* Remove the no-longer-needed "global runtime" code.Nick Mathewson2021-04-172-8/+3
|
* Remove some cruft in tor_rtcompat::implsNick Mathewson2021-04-172-27/+4
|
* rtcompat: Make TLS functionality use Runtime traits.Nick Mathewson2021-04-162-6/+51
| | | | | Now there is nothing in principle that you couldn't access from a Runtime implementation.
* Make incoming Streams of TcpStream a real type for each backend.Nick Mathewson2021-04-162-0/+86
| | | | | This makes things a little more complicated for AsyncStd, and a little simpler for Tokio.
* Port tor_rtcompat::net to use Runtime objects.Nick Mathewson2021-04-161-16/+0
|
* Port tor_rtcompat::timer to use Runtime objects.Nick Mathewson2021-04-162-27/+3
|
* Begin a refactoring of tor-rtcompat to use runtime objects.Nick Mathewson2021-04-162-22/+103
| | | | | | | | So far, all traits are defined (I hope) and the task api is ported. With time I want to have none of the current "global runtime" APIs exposed, and just use Runtime objects instead. But that isn't just yet.
* rtcompat: Add a cancellable-task-handle type.Nick Mathewson2021-04-092-4/+24
| | | | | | | The API is a bit yucky, since it has to be compatible with tokio and async_std. (Also, this patch fixes some async_std clippy warnings)
* Move responsibility for knowing about TLS into tor_rtcompat.Nick Mathewson2021-03-232-0/+165
| | | | Now we don't need runtime-specific stuff in tor-chanmgr.
* Refactor tokio implpementation in tor-rtcompat.Nick Mathewson2021-03-231-6/+116
| | | | | | | | | | | Now other crates don't need any 'ifdef tokio' code, since there are wrappers that implement 'futures' right. Technically, the 'futures' traits are in some ways less good than the tokio ones, but we need a consistent API if we want to support WASM someday and keep support for async_std. I'd rather hold out hope for a future version of futures::io working like tokio than to fix ourselves into the tokioverse forever.
* Port to work with tokio or async-std.Nick Mathewson2021-03-022-1/+71
| | | | | | | | | | | | | | | | | | 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.
* tor-dirclient: add timeoutsNick Mathewson2020-12-011-1/+1
| | | | | | | | This adds two timeouts in total: one for sending begin, and getting headers, and one for getting the rest of the data. These timeouts are way too long right now, but at least the code is there.
* Require documentation in tor-rtcompat.Nick Mathewson2020-11-201-0/+10
|
* tor-chanmgr: timeout support.Nick Mathewson2020-11-111-0/+1
|
* Document tor-rtcompat crate a littleNick Mathewson2020-11-111-1/+1
|
* Isolate async_std usage in a new tor_rtcompat crate.Nick Mathewson2020-11-111-0/+11
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.