composia-dave opened PR #14252 from composia-dave:wasi-file-input-stream-blocking-read to bytecodealliance:main:
FileInputStream::readin theIdlestate always spawns a background read and answers an empty chunk, even when the file was opened underWasiCtxBuilder::allow_blocking_current_thread(true)— the flag that already makes the descriptor-levelread,write,statetc. run on the current thread (File::run_blocking/as_blocking_file). Theblocking_readpath honours it, but a guest using the non-blockingread(wasi-libc's stream reads, e.g. CPython's file I/O) gets a number of empty answers that depends on how quickly the blocking pool runs the task — i.e. on host load.That is guest-observable: for a Wizer-style pre-initialization snapshot (componentize-py) the guest's read-loop iteration count ends up in the heap, and two runs of the same snapshot differed by 42 bytes on a quiet machine and 14.8 MB with a concurrent build running. With this change, a file opened under the flag is read synchronously in
readtoo, and that divergence is gone (measured against 46.0.1 with this same hunk; ported here unchanged — the surrounding code is identical onmain).Behaviour for files NOT opened under the flag is unchanged (the background read stays). The change reuses
as_blocking_fileand the existingblocking_readhelper, and delivers the first chunk from the resultingReadStatedirectly, keepingpositionand theIdle/DataAvailabletransitions the same as the existingDataAvailablearm.The wider context (what a pre-init snapshot still observes through
wasmtime-wasionce random, clocks and env are pinned) is #14251.
composia-dave requested pchickey for a review on PR #14252.
composia-dave requested wasmtime-wasi-reviewers for a review on PR #14252.
github-actions[bot] added the label wasi on PR #14252.
Last updated: Sep 20 2026 at 18:08 UTC