summaryrefslogtreecommitdiff
path: root/tor-rtcompat
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove need for async_trait in SleepProviderExtNick Mathewson2021-04-171-11/+42
|
* Move timer functions into an extension trait.Nick Mathewson2021-04-172-112/+110
|
* Move around the public modules in tor_rtcompat.Nick Mathewson2021-04-171-1/+8
|
* Remove all non-runtime methods in tor_rtcompat.Nick Mathewson2021-04-161-32/+5
|
* Add a "Runtime" parameter to all the manager types.Nick Mathewson2021-04-162-4/+20
| | | | | This is a big change, but it is a step towards our goal of removing tor_rtcompat:: calls directly.
* rtcompat: Make TLS functionality use Runtime traits.Nick Mathewson2021-04-164-45/+94
| | | | | Now there is nothing in principle that you couldn't access from a Runtime implementation.
* Move the "sleep()" function from task to timer.Nick Mathewson2021-04-161-9/+7
|
* Make incoming Streams of TcpStream a real type for each backend.Nick Mathewson2021-04-164-39/+90
| | | | | 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-162-17/+41
|
* Port tor_rtcompat::timer to use Runtime objects.Nick Mathewson2021-04-163-29/+60
|
* Begin a refactoring of tor-rtcompat to use runtime objects.Nick Mathewson2021-04-165-27/+187
| | | | | | | | 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: rename traits module to impl_traits.Nick Mathewson2021-04-161-1/+1
|
* 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-235-3/+203
| | | | Now we don't need runtime-specific stuff in tor-chanmgr.
* Refactor tokio implpementation in tor-rtcompat.Nick Mathewson2021-03-232-9/+122
| | | | | | | | | | | 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.
* Add appropriate categories to some Cargo.toml files.Nick Mathewson2021-03-171-0/+1
|
* Add the tor project as an author.Nick Mathewson2021-03-171-1/+1
|
* Add keywords to each Cargo.tomlNick Mathewson2021-03-171-0/+1
|
* Add a description field to all our Cargo.toml filesNick Mathewson2021-03-171-0/+1
|
* Give it a homepage everyplace.Nick Mathewson2021-03-171-0/+1
|
* Cut down on tokio features.Nick Mathewson2021-03-101-1/+1
|
* Bump dependencies with "cargo upgrade"Nick Mathewson2021-03-061-1/+1
|
* Update docs wrt tokio a bitNick Mathewson2021-03-021-5/+16
|
* Port to work with tokio or async-std.Nick Mathewson2021-03-025-3/+99
| | | | | | | | | | | | | | | | | | 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.
* Write a few misc unit testsNick Mathewson2020-12-151-6/+35
|
* rtcompat: add a function to sleep until a given wallclock timeNick Mathewson2020-12-041-1/+36
| | | | | (We can't just subtract and sleep, since we should be at least somewhat concerned about clock jumps.)
* Upgrade async-ioNick Mathewson2020-12-031-1/+1
|
* Bump to latest async-ioNick Mathewson2020-12-011-1/+1
|
* 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-203-11/+29
|
* tor-chanmgr: timeout support.Nick Mathewson2020-11-111-0/+1
|
* Document tor-rtcompat crate a littleNick Mathewson2020-11-112-3/+12
|
* Remove a couple of unused dependenciesNick Mathewson2020-11-111-5/+0
|
* Isolate async_std usage in a new tor_rtcompat crate.Nick Mathewson2020-11-114-0/+42
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.