## Motivation
The `CurrentThread` runtime's `Handle` is different than the
`CurrentThread` executor's `Handle`. This causes interoperability issues
with custom runtimes that build on the `CurrentThread` executor.
Actix-rt offers a concrete example of the issue: [`System::run_in_executor`][1]
requires a `CurrentThread` executor handle - the change in this PR
allows a `CurrentThread` runtime to be used here.
## Solution
This PR adds `fn into_inner(self)` on the runtime `Handle` that consumes
it and returns the underlying `CurrentThread` executor's `Handle`.
[1]: https://docs.rs/actix-rt/0.2.6/actix_rt/struct.System.html#method.run_in_executor
tokio-uds 0.2.4 has the `UnixDatagramFramed` which is reexported here
and tokio-threadpool 0.1.16 uses a new enough rand that compiles with
modern toolchains.
## Motivation
The initial version of `tokio-compat`'s compatibility runtime added in
#1663 doesn't support the calls to `tokio_threadpool` 0.1's `blocking`.
This is because (unlike the timer, executor, and reactor), there's no
way to override the global `blocking` functionality in
`tokio-threadpool`.
## Solution
As discussed [here][1], this branch adds APIs to the v0.1.x version of
`tokio-threadpool` that allow overriding the behavior used by calls to
`blocking`. The threadpool crate now exposes `blocking::set_default` and
`blocking::with_default` functions, like `executor`, `timer`, and
`reactor`. This will allow `tokio-compat` to override calls to 0.1's
`blocking` to use the new `tokio` 0.2 blocking APIs.
Unlike the similar APIs in `executor`, `timer`, and `reactor`, the hooks
for overriding blocking behaviour are `#[doc(hidden)]` and have comments
warning against their use outside of `tokio-compat`. In general, there
probably won't be a compelling reason to override these outside of the
compatibility layer.
Refs: #1722
[1]: https://github.com/tokio-rs/tokio/pull/1663#issuecomment-548661766
Signed-off-by: Eliza Weisman <[email protected]>
This commit adds `set_default` drop guard style APIs for setting the
default reactor, executor, and timer. These are similar to the APIs used
in `tokio` 0.2
In addition to having potentially better ergonomics than the
`with_default` closure APIs, the drop-guard based APIs will be helpful
in rewriting the `tokio-compat` crate to wrap the existing tokio 0.2
runtime, rather than constructing its own runtime.
Because the runtime does not expose an `around_worker` API, it cannot
currently be used with the 0.1 `with_default` method of setting the
reactor, timer, and executor. This means that tokio-compat must
duplicate a lot of existing code from `tokio` to construct the runtime,
which is unfortunate (and has the potential to introduce errors). On the
other hand, we can use the drop guard APIs with `before_start` and
`after_stop`, by storing the drop guards in a thread-local. This will
allow `tokio-compat` to wrap the 0.2 runtime, reducing code duplication.
Also, this will allow the blocking pool to be used on the compat
runtime, which is currently impossible (as the blocking APIs are private
to `tokio`).
Signed-off-by: Eliza Weisman <[email protected]>
## Motivation
Currently, the tests for `tokio` 0.1's async-await support build against a
fairly old nightly from Rust 1.36. Upstream changes to a transitive
dependency introduced a use of `MaybeUninit`, which is feature
flagged on this nightly. This resultedin [0.1.x builds breaking][1].
The `tokio` 0.1 async-await support has not been maintained, in favour
of working on 0.2. It currently uses severely outdated versions of the
async-await APIs (including the `await!` macro). Anyone using
async-await with Tokio is almsot certainly on 0.2 by now.
## Solution
Since the 0.1 async-await APIs are both unused and unmaintained, this
branch deletes them.
[1]: https://dev.azure.com/tokio-rs/Tokio/_build/results?buildId=3174&view=logs&jobId=ba363064-0d45-526e-6c63-c7e816804fbe&taskId=3aff0ee6-e312-56d4-f5d3-d804e6c343c3&lineStart=83&lineEnd=87&colStart=1&colEnd=1
Signed-off-by: Eliza Weisman <[email protected]>
When polling the task, the current waker is saved to the oneshot state.
When the handle is migrated to a new task and polled again, the waker
must be swaped from the old waker to the new waker. In some cases, there
is a potential for the old waker to leak.
This bug was caught by loom with the recently added memory leak
detection.
Backport of #1648.
* upgrade to rand 0.7.0 (MSRV 1.32)
* upgrade to parking_lot 0.9.0
* Remove last non-dev dependency on rand crate (#1324)
Use std RandomState for XorShift seeding. This allows dropping _rand_
crate dep here, accept as a dev dependency for tests or benchmarks.
* increase CI MSRV to 1.31.0
* increase nightly for CI TSAN tests
* add TSAN suppressions for recent rand related updates
* make latest TSAN suppression patterns more general
* upgrade tempfile dev dep for common rand version
But avoid tempfile 3.2 for now, since history demonstrates it bumps
rand versions and MSRV in MINOR updates.
* update (dev dep) env_logger to latest 0.6
* reactor, threadpool: bump PATCH versions, doc links, change logs [ci-release]
* use dyn Trait syntax where appropriate
recent rust nightly started warning that not using `dyn` was
deprecated. This requires MSRV 1.27.0+.
* rustfmt fallout from dyn additions
* stop explicit allow of rust_2018_idioms
* more dyn Trait syntax
* drop tokio-macros from 0.1.x workspace
Since tokio-macros specifies an edition=2018, we would otherwise
require MSRV 1.31.0 to build/test it. And tokio-macros isn't used with
tokio 0.1.x.
* reactor: narrow tokio-io-pool dev dep to 0.1.4
Since 0.1.5-6 is now a edition=2018 crate, which has effective MSRV
1.31.0.
* narrow tempfile dev-dep to avoid MSRV bump
tempfile 3.1.0 pulls in rand 0.7.0 and is MSRV 1.32.0
* narrow flate2 dev-dep to avoid MSRV bump
flate2 1.0.10-11 have MSRV 1.34.0.
github refs: alexcrichton/flate2-rs#207
* fs: drop deprecated tempdir crate use in tests
In particular because it pulls in old rand duplicates. Replace use
with tempfile::tempdir() which has been available since tempfile
3.0.0.
backport-of: #1312
* increase CI MSRV to 1.28.0
* chore: remove `tokio-trace`, add "Related Projects" to README (#1221)
The `tokio-trace` and `tokio-trace-core` crates have been renamed to
`tracing` and `tracing-core`, and moved to their own repository
(`tokio-rs/tracing`).
This branch removes `tokio-trace` and `tokio-trace-core` from the
`tokio` repository. In addition, I've added a "Related Projects" section
to the root README, which lists `tracing` (as well as `mio`, and
`bytes`) as other libraries maintained by the Tokio project. I thought
that this would help folks looking for `tokio-trace` here find it in its
new home.
In addition, it changes `tokio` to depend on `tracing-core` rather than
`tokio-trace-core`.
Closes#1159
Signed-off-by: Eliza Weisman <[email protected]>
* Remove erroneous add of `tokio-macros`
* Some more tokio-trace remnants
* Remove tokio-trace remnants from Cirrus CI
* disable tracing-core feature by default
It can't build on Rust 1.26.0
Signed-off-by: Eliza Weisman <[email protected]>
* fix feature flagging
Signed-off-by: Eliza Weisman <[email protected]>
Lucio Franco