-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update stdio on Unix to fall back to worker threads #6833
Update stdio on Unix to fall back to worker threads #6833
Conversation
My plan was to fall back on the worker thread implementation if asyncfd cant be created, rather than always use asyncfd. |
Not all file descriptors can get registered with epoll, for example files on Linux or `/dev/null` on macOS return errors. In these situations the fallback of the worker thread implementation is used instead.
378be36
to
bc72bd2
Compare
Sounds good to me 👍 I've updated this to implement that instead. One concern I had about that approach is that historically in Rust I've been bitten about how the nonblocking flag affects the file description, not to be confused with the file descriptor. For example if many processes share the same stdout then if any of them set stdout to nonblocking then they all have a nonblocking stdout (which most are not prepared for). I'm a little concerned about Wasmtime here marking stdin as nonblocking since it could affect other components of the runtime too. I've confirmed locally though that at the very least I do still think there's a possibility for problems when Wasmtime is integrated with FFI for example, but I'm ok to wait for a bit and see if that crops up |
…#6833) Not all file descriptors can get registered with epoll, for example files on Linux or `/dev/null` on macOS return errors. In these situations the fallback of the worker thread implementation is used instead.
…time into feature/wasi-nn-preview-2 * 'feature/wasi-nn-preview-2' of github.com:geekbeast/wasmtime: Memcheck for Wasm guests in Wasmtime (bytecodealliance#6820) CI: upgrade to qemu 8.0.4. (bytecodealliance#6849) Sync wasi-cli with wit definitions in standards repo (bytecodealliance#6806) Rename `preview2::preview2` to `preview2::host` (bytecodealliance#6847) winch: Simplify the MacroAssembler and Assembler interfaces (bytecodealliance#6841) There are no files in `preview1` other than `mod.rs` (bytecodealliance#6845) Update stdio on Unix to fall back to worker threads (bytecodealliance#6833) Update RELEASES.md (bytecodealliance#6838) Minor documentation updates to docs/WASI-tutorial.md (bytecodealliance#6839) Add support for vector in DataValueExt::int() (bytecodealliance#6844)
This commit is a follow-up to bytecodealliance#6833 to remove the `unix` module for handling stdio which sets stdin to nonblocking mode. I've just now discovered that on macOS at least configuring `O_NONBLOCK` for stdin affects the stdout/stderr descriptors too. This program for example will panic: fn main() { unsafe { let r = libc::fcntl( libc::STDIN_FILENO, libc::F_SETFL, libc::fcntl(libc::STDIN_FILENO, libc::F_GETFL) | libc::O_NONBLOCK, ); assert_eq!(r, 0); } loop { println!("hello"); } } It was originally assumed that updating the flags for stdin wouldn't affect anything else except Wasmtime, but because this looks to not be the case this commit removes the logic of registering stdin raw with Tokio and instead unconditionally using the worker thread solution which should work in all situations.
This commit is a follow-up to #6833 to remove the `unix` module for handling stdio which sets stdin to nonblocking mode. I've just now discovered that on macOS at least configuring `O_NONBLOCK` for stdin affects the stdout/stderr descriptors too. This program for example will panic: fn main() { unsafe { let r = libc::fcntl( libc::STDIN_FILENO, libc::F_SETFL, libc::fcntl(libc::STDIN_FILENO, libc::F_GETFL) | libc::O_NONBLOCK, ); assert_eq!(r, 0); } loop { println!("hello"); } } It was originally assumed that updating the flags for stdin wouldn't affect anything else except Wasmtime, but because this looks to not be the case this commit removes the logic of registering stdin raw with Tokio and instead unconditionally using the worker thread solution which should work in all situations.
…liance#7058) This commit is a follow-up to bytecodealliance#6833 to remove the `unix` module for handling stdio which sets stdin to nonblocking mode. I've just now discovered that on macOS at least configuring `O_NONBLOCK` for stdin affects the stdout/stderr descriptors too. This program for example will panic: fn main() { unsafe { let r = libc::fcntl( libc::STDIN_FILENO, libc::F_SETFL, libc::fcntl(libc::STDIN_FILENO, libc::F_GETFL) | libc::O_NONBLOCK, ); assert_eq!(r, 0); } loop { println!("hello"); } } It was originally assumed that updating the flags for stdin wouldn't affect anything else except Wasmtime, but because this looks to not be the case this commit removes the logic of registering stdin raw with Tokio and instead unconditionally using the worker thread solution which should work in all situations.
Not all file descriptors can get registered with epoll, for example
files on Linux or
/dev/null
on macOS return errors. In thesesituations the fallback of the worker thread implementation is used
instead.