| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
| |
This makes things a little more complicated for AsyncStd, and a
little simpler for Tokio.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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)
|
| |
|
|
| |
Now we don't need runtime-specific stuff in tor-chanmgr.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
(We can't just subtract and sleep, since we should be at least
somewhat concerned about clock jumps.)
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
|
|
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.
|