In #6112, tests for the tracing instrumentation were introduced. They
had to live in their own test crate under `tokio/tests` because the
`tracing-mock` crate that the tests use had not yet been published to
crates.io.
Now `tracing-mock` has been published to crates.io and so the separate
test crate and separate job to run it are no longer necessary. The
tracing instrumentation tests can be placed in with the other
integration tests in the `tokio` crate.
The tests themselves have also been updated to match the changes in the
`tracing-mock` API since the version which was being used.
## Motivation
As described in #6763, Tokio compiles for the [illumos] operating
system, but we don't presently have automated tests on illumos. We would
like to add illumos CI jobs for Tokio using [Buildomat], a CI system
which supports illumos. Buildomat CI jobs for Tokio will run on
infrastructure contributed by Oxide Computer Company.
In order for Buildomat to watch for commits to the repo, we must first
add a configuration file in `.github/buildomat/config.toml` with the
`enable = true` key. This config file must be present on the repo's main
branch for Buildomat to enable builds for the repo. See [here] for
details.
## Solution
This branch adds a `.github/buildomat` directory containing a config
file and a README summarizing what the configs in that directory are
for, as well as documenting how to get help diagnosing illumos CI
failures.
This branch does *not* add scripts for actually running CI jobs on
Buildomat. Since the config file must be present on the repo's main
branch before Buildomat runs CI jobs for the repo, I'd like to merge the
config file separately from the actual build scripts. This way, I can
actually have the build jobs run on the PR that adds them, making it
easier to ensure everything is working correctly before merging.
Closes#6766, which is obsoleted by this branch.
[illumos]: https://www.illumos.org/
[Buildomat]: https://github.com/oxidecomputer/
[here]:
https://github.com/oxidecomputer/buildomat/blob/main/README.md#per-repository-configuration
Tokio is instrumented with traces which can be used to analyze the
behavior of the runtime during execution or post-mortem. The
instrumentation is optional. This is where tokio-console collections
information.
There are currently no tests for the instrumentation.
In order to provide more stability to the instrumentation and prepare
for future changes, tests are added to verify the current behavior. The
tests are written using the `tracing-mock` crate. As this crate is still
unreleased, a separate test create has been added under `tokio/tests`
which is outside the workspace. This allows us to pull in both `tracing`
and `tracing-mock` from the tracing repository on GitHub without
affecting the rest of the tokio repository.
This change adds initial tests for the task instrumentation. Further
tests will be added in subsequent commits.
Once `tracing-mock` is published on crates.io (tokio-rs/tracing#539),
these tests can be moved in with the "normal" tokio integration tests.
The decision to add these tests now is due to the release of
`tracing-mock` taking a while, so it would be better to have tests while
we wait.
Currently, Tokio runs cross-compilation checks for the
`mips-unknown-linux-gnu` and `mipsel-unknown-linux-musl` target triples.
However, Rust has recently demoted these targets from Tier 2 support to
Tier 3 (see rust-lang/compiler-team#648). Therefore, MIPS toolchains may
not always be available, even in stable releases. This is currently
[breaking our CI builds][1], as Rust 1.72.0 does not contain a standard
library for `mips-unknown-linux-gnu`.
This branch removes these builds from the cross-compilation check's
build matrix. Tokio may still build successfully for MIPS targets, but
we can't easily guarantee support when the stable Rust release train may
or may not be able to build for MIPS targets.
[1]: https://github.com/tokio-rs/tokio/actions/runs/5970263562/job/16197657405?pr=5947#step:3:80
Since MSRV is bumped to 1.63, `Mutex::new` is now usable in const context.
Also use `assert!` in const function to ensure correctness instead of
silently truncating the value and remove cfg `tokio_no_const_mutex_new`.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
This patch includes an initial implementation of a new multi-threaded
runtime. The new runtime aims to increase the scheduler throughput by
speeding up how it dispatches work to peer worker threads. This
implementation improves most benchmarks by about ~10% when the number of
threads is below 16. As threads increase, mutex contention deteriorates
performance.
Because the new scheduler is not yet ready to replace the old one, the
patch introduces it as an unstable runtime flavor with a warning that it
isn't production ready. Work to improve the scalability of the runtime
will most likely require more intrusive changes across Tokio, so I am
opting to merge with master to avoid larger conflicts.
