WASIX: __asyncify_light
ignores the timeout argument
#4935
Labels
🕵️ needs investigation
The issue/PR needs further investigation
priority-medium
Medium priority issue
Describe the bug
I am implementing nonblocking stdin support for Wasmer and Wasmer JS. During exploring the code, I noticed that
fd_read
never timed out and is blocked indefinitely despite the detection ofNONBLOCK
status flag.__asyncify_light
was supposed to handle thattimeout
parameter and errored out, just like what was done in__asyncify_with_deep_sleep
, but it appeared to be ignored.Given all the usage of
__asyncify_light
are either supplying zero timeout as a nonblocking mechanism or does not use timeout at all, the timeout parameter can be replaced with a simplebool
. Most polling logic use thewith_deep_sleep
version. I guess that the distinction is that not all environment (e.g., Wasmer JS SDK without COEP/COOP) supports deep sleeping.I use my own fork to reproduce. It is based on an old version, v4.2.5, used by Wasm.js, but this issue presents in the main branch.
wasmer -vV; rustc -vV wasmer 4.2.5 (129428a 2024-07-16) binary: wasmer-cli commit-hash: 129428adb302626cf0ef8d12aec8485a8c102e93 commit-date: 2024-07-16 host: aarch64-apple-darwin compiler: singlepass,cranelift rustc 1.70.0 (90c541806 2023-05-31) binary: rustc commit-hash: 90c541806f23a127002de5b4038be731ba1458ca commit-date: 2023-05-31 host: aarch64-apple-darwin release: 1.70.0 LLVM version: 16.0.2
Steps to reproduce
N/A because nonblocking read is not available under normal circumstances, but it might be patched like above to allow one. It is actually better tested in Wasmer JS SDK since the blocking read from Tokio's stdin implementation cannot be cancelled. I can provide more context if required.
Expected behavior
Under nonblocking mode set to stdin (fd=0),
fd_read
returns immediately no matter whether any data is available.Actual behavior
fd_read
blocks until some data is available.Additional context
To work toward a fix, I would like to first understand the distinction between the light version and the deep sleep one, and if a zero-or-infinite timeout makes sense, e.g., actually "lighter", provides more compatibility, etc.
The text was updated successfully, but these errors were encountered: