-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Support for pipes in poll_oneoff on Windows #870
Comments
I don't think we should ever translate a poll call to a busyloop; applications calling poll expect to properly sleep, not busyloop. It may be possible to implement waiting on pipes / named pipes by using overlapped I/O. It's a different model than the UNIX-style select model (it supplies the data when ready, and not just an indication of data available), and it may have some impedance mismatch, but it should allow waiting on input without spinning. |
This would require a major overhaul of the whole I/O implementation. Since overlapped I/O provides the data when it's available, wasmtime would need to buffer all (or some) I/O, so that it's not silently dropped. On the other hand, using overlapped I/O (if viable) would also remove the necessity to spin up a separate thread when polling stdin. |
FWIW, nonblocking calls are on the roadmap for |
We're currently using Lucet's suspend/resume functionality so that we can implement non-WASI(-yet) HTTP interfaces using |
#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 unknownI 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
andENOTSUP
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 forENOTSUP
. (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 inpath_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:wasmtime/crates/test-programs/tests/wasm_tests/runtime.rs
Lines 34 to 35 in 1defae2
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 #552What do you think, should we properly support polling of pipes in wasmtime?
cc @kubkon @sunfishcode @peterhuene
The text was updated successfully, but these errors were encountered: