Every atomic operation on `Notify::state` used `SeqCst`. Nothing needs
the global total order: every lock-avoidance decision is made by an RMW,
which always reads the latest value in that atomic's modification order,
and every stale load is re-validated either by a following RMW or by a
re-load under the `waiters` mutex.
What the `state` orderings do have to carry is the happens-before for
data published before `notify_one`, consumed through the permit
compare-exchange, and for data published before `notify_waiters`,
consumed through the counter check. Acquire/release on `state` provides
both. The waiter list is ordered by the mutex, and `AtomicNotification`
by its own release/acquire pair, so neither depends on these orderings.
Loads become `Acquire`, stores `Release`, compare-exchange
`(AcqRel, Acquire)`, and the `notify_waiters` counter increment
`AcqRel`. All nineteen sites are converted, so no `SeqCst` is left
alongside weaker orderings.
Fixes: #6266
The Builder::new, new_codec, and new_read doc examples combined
length_adjustment(0) with num_skip(0). This leaves the length
header bytes in the buffer without accounting for them, so decoding
returns a frame that includes the raw header at the front and is
short at the back, corrupting the following frame.
Drop num_skip(0) so the default (skip the header) behavior applies,
and turn all three examples into executable doctests that perform a
real encode/decode round-trip and assert on the payload, so this
class of bug is caught automatically going forward.
Fixes: #8348
The reservation used `n`, the length after `length_adjustment` has been
applied, but the encoder goes on to write `length_field_len` bytes of
header plus `data.len()` bytes of payload. A positive `length_adjustment`
therefore under-reserved by exactly the adjustment on every frame, and a
negative one over-reserved, so the reservation did not match the write in
either of the adjusted configurations shown in the module docs.
Add an explicit tracking knob and expose the sampled task schedule
latency through TaskMeta. Reuse the histogram poll timestamp where
possible and preserve grouped histogram accounting for LIFO polls.
Document activation and interval semantics and cover current-thread,
multi-thread, LIFO, disabled, and non-poll callback behavior.
These tests were temporarily disabled until required `wasi-libc` fixes made
their way into a Rust release. Now that that has happened, we can enable them.
Note that `send_to_recv_closed_returns_err` remains disabled for a bit longer.
The applicable `wasi-libc` bug was masking a separate bug in Wasmtime, fixed
[here](https://github.com/bytecodealliance/wasmtime/pull/13933). Once that fix
makes its way into a release (presumably v48.0.0), we'll finally be able enable
that test, and that should be the last of the
temporarily-disabled-on-WASI-due-to-bugs tests.
Per https://github.com/bytecodealliance/wasmtime/pull/13558, Wasmtime v46.0.1
was the last release to support `wasm32-wasip1-threads`, so we use that for the
WASIp1 testing.
For WASIp2, we should be able to use any recent version of Wasmtime, but we pin
to a specific version anyway to avoid surprises.
OnceLock::wait was stabilized in Rust 1.86, so its use in the Windows
console ctrl handler broke tokio's declared rust-version of 1.71 on
windows targets in 1.53.0 (any cargo check with a 1.71..1.86 toolchain
fails with E0599).
The wait existed only because SetConsoleCtrlHandler was called inside
REGISTRY's get_or_init closure, i.e. before the OnceLock was actually
initialized, leaving a window where an invoked handler could observe an
uninitialized REGISTRY. Initialize the registry first and register the
OS handler afterwards (exactly once, through a second OnceLock that
also caches a registration failure so every subsequent call reports the
same error, matching the previous behavior). The handler can then rely
on plain get(): registration happens-after initialization, so an
invoked handler always finds the registry.
Verified with cargo +1.71 check -p tokio --features full
--target x86_64-pc-windows-msvc (fails with the reported E0599 before
this change, clean after) and --all-targets on stable for the same
target.
Fixes#8299
Rachit2323