[charlespers]

Repo: tokio-rs/tokio · base: 060cc4e ("wasm: support the wasm32-unknown-emscripten target (#8281)") · branch: charles-fix-tokio

Title

emscripten: keep cooperative yielding in the inline blocking shim

Body

On non-pthread wasm32-unknown-emscripten, crate::blocking::spawn_blocking runs the closure
inline and returns std::future::Ready, and the internal JoinHandle alias is that Ready.
The native task::JoinHandle::poll calls coop::poll_proceed before reading the output;
Ready::poll does not, and none of the consumers (fs::File, fs::ReadDir,
io::blocking::Blocking behind stdin/stdout/stderr) check the budget themselves. A task
looping over always-ready file operations therefore never returns Pending and never lets any
other task or timer run on the single-threaded runtime. The existing fs_file::coop test shows
it: on 060cc4e (with the #[ignore] lifted) the test's first task.poll() never returns — the
run had to be killed after 30 s.

The shim now wraps the completed future in the existing public coop::Coop via
coop::cooperative(...), so polling it consumes one unit of budget and yields when the budget
is exhausted, exactly like the native handle; Coop gains #[derive(Debug)] because the
consumer State enums derive Debug through the alias. The #[cfg_attr(emscripten, ignore)]
on fs_file::coop is removed and the test passes on the target (node runner, emsdk 6.0.9).

Separately, three emscripten test gates listed fewer features than the file uses:
task_emscripten.rs (needs rt, macros), io_emscripten.rs (needs io-util, rt,
macros) and time_timeout.rs (needs io-util). With a narrower feature set those crates
failed to compile instead of being skipped; the gates now name every feature they need.
Note that --no-default-features --features sync --tests still does not compile on any target
because the pre-existing sync_* tests use tokio::test while gating only on sync; that is
outside this change.

Severity

• Coop starvation: medium on this target (fairness/latency; a file-I/O loop can monopolise the
  runtime). Not a regression versus the pre-feat: support the wasm32-unknown-emscripten target #8281 tree, where fs on emscripten did not build.
• Test gating: low; test-crate hygiene only. CI runs one feature set and does not observe it.
• Stdin test "hangs when interactive" (claim fable-4): not reproduced. With stdin attached
  to a pty that never receives input, the 060cc4e test returns immediately. No change made.

Verification

• cargo test --target wasm32-unknown-emscripten ... --test fs_file -- coop --include-ignored
  on 060cc4e: never finishes (killed at 30 s). With the fix: test coop ... ok.
• Full CI emscripten command --features "rt,time,sync,macros,fs,io-util,io-std,test-util" --tests
  with -Dwarnings: 752 passed, 0 failed, 9 ignored.
• cargo check --target wasm32-unknown-emscripten --no-default-features --features rt --test task_emscripten
  (and io-std/io_emscripten, rt,macros/time_timeout): error on 060cc4e, clean with the fix.
• Native: cargo test --features full --test fs_file --test io_read --test task_blocking ok; cargo fmt --check clean.
• Upstream tokio/src/blocking.rs, tests/io_emscripten.rs, tests/task_emscripten.rs on
  master were byte-identical to this case head at the time of writing.

[guybedford]

This seems correct to me.

[Darksonn]

Why is this being added?

[Darksonn]

Thanks