Stream: git-wasmtime

Topic: wasmtime / issue #870 Support for pipes in poll_oneoff on...

Wasmtime GitHub notifications bot (May 28 2026 at 02:51):

alexcrichton closed issue #870:

#552 introduced a minimal viable implementation of poll_oneoff, which consciously did not properly support the following file types on Windows: (quoting MSDN)

• FILE_TYPE_CHAR - a character file, typically an LPT device or a console.
• FILE_TYPE_PIPE - a socket, a named pipe, or an anonymous pipe.
• FILE_TYPE_UNKNOWN - type of the specified file is unknown

I think it's completely fine not to support character files. The most common use case, the Windows console, is already handle by Descriptor::Stdin and friends. Otherwise, it seems to be mostly used for devices connected using the LPT and COM ports. Support for this in wasmtime looks completely out of scope. There seems to be no way of peeking the character files or polling them in any sensible way.

I'm unsure about the error code to be returned, hesitating between EINVAL and ENOTSUP and am more inclined toward the latter. It's not an invalid argument but an operation that is not supported on the file descriptor. (this the way it was handled in #552)

When the file is FILE_TYPE_UNKNOWN, we can't basically do anything useful with it, so I'd go for ENOTSUP. (i.e. stick with the current implementation)

I'm unsure about pipes. We don't support sockets yet and wasm applications have no way of creating pipes on their own. It looks like it's also impossible for the app to open a named pipe created by another process, because paths of form \\.\pipe\PipeName are not available in path_open.
It seems that the only way an app could possibly have access to a pipe would be through WasiCtx, analogously to what is done here:
https://github.com/bytecodealliance/wasmtime/blob/1defae27426d51105867fd8327db099d75da70b4/crates/test-programs/tests/wasm_tests/runtime.rs#L34-L35
As for the implementation, we could possibly use PeekNamedPipe to find out whether there's any data available inside the pipe, but this would require a busy looping with sleep, similarly to what was done in the initial implementation of #552

What do you think, should we properly support polling of pipes in wasmtime?

cc @kubkon @sunfishcode @peterhuene

Wasmtime GitHub notifications bot (May 28 2026 at 02:51):

alexcrichton commented on issue #870:

I'm going to close this since wasi-common is now deprecated and slated to be removed, so we're unlikely to make major changes to wasi-common at this point

Last updated: Jun 01 2026 at 09:49 UTC