These tests were added in #3569 (2021) but immediately marked
`#[ignore]` because of a then-known bug where shutting down the io
driver while concurrently registering new resources was unsound.
That bug class was resolved by the io driver rewrite in #5833, which
replaced the slab-based registration with a `RegistrationSet` guarded by
a mutex-protected `Synced`. Allocating a new registration now checks
`is_shutdown` under the lock and returns a proper error instead of
racing, so binding a resource after (or concurrently with) runtime
shutdown fails deterministically.
Re-enable the 7 ignored tests (across the 3 scheduler configurations).
Five of them pass unchanged. The two `unix_listener_shutdown_after_*`
tests asserted the old `"reactor gone"` message; #5833 unified that path
onto the single `RUNTIME_SHUTTING_DOWN_ERROR` string, so update those two
assertions to the current message.
`Lines` accumulated into a `String`, so a partial line interrupted by an
I/O error could not be kept when it ended mid multi-byte character. The
next poll then tripped `debug_assert!(output.is_empty())`, or
underflowed `vector.len() - num_bytes_read` in `put_back_original_data`,
which panics in release builds too on the `.expect` below it.
`Lines` now holds a single `buf: Vec<u8>` and calls
`read_until_internal` directly the way `Split` does, converting to
`String` only once a whole line is available.
An `InvalidData` error now carries the utf-8 error itself rather than a
fixed string. `Lines` owns the line, so it hands over the whole
`FromUtf8Error` and the caller can still recover the bytes; `read_line`
and `read_to_string` have to put those bytes back into the caller's
`String`, so they carry `Utf8Error` instead.
`read_line_internal` has no callers outside `read_line.rs` and is now
private.
Re-lands the sharded queue from #7757 (reverted due to #8056), disabled by
default. Opt in via the unstable `Builder::enable_sharded_blocking_queue` or
the `TOKIO_UNSTABLE_SHARDED_BLOCKING_QUEUE` environment variable.
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.
