-
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't access stdin from a WASI program generated by AssemblyScript #2373
Comments
Thanks for the report! This seems like it may be an issue with the wasi support in AssemblyScript possibly, so I'm gonna loop in @torch2424 to see if they can help (or help point you in the right direction) |
Could it be this line that returns null when bytes read = 0 (i.e it always returns null because it'll read a 0 to indicate end of stream)? |
Thanks for looping me in @alexcrichton 馃槃 And yes, @peterhuene , I bet it's falling through to the bottom to return 0 馃槃 @flavio I was able to reproduce this, and what caught my interest was:
So! Yes, in most instances, I've personally noticed stdin was represent by 0. Or perhaps it does on Mac? But! If you can't get a file descriptor for stdin at 0, then yes it could totally be the cause of this bug. cc @jedisct1 , as they are the author of as-wasi, and they may have a better hunch than me 馃槃 |
@torch2424 it's fine on Unix to have the STDIN -> 0, STDOUT -> 1 and STDERR -> 2. I'm not surprised by that :) |
Yes, STDIN->0, STDOUT->1, STDERR->2 is true of WASI today, so it's fine to rely on for now. That said, this is something that may change in the future, at the WASI level. The 0,1,2 values are required in POSIX so we'll always need a way to let applications that need this numbering to get it, but we may also want more flexibility for applications that don't need it. |
Hi, This is a misunderstanding of what the The
In order to read a line of text, you need to read bytes until you reach a The current version of |
Perhaps I misunderstood, but I don't think there was confusion over a newline causing a termination of the stream. I think the problem is that @flavio was observing I believe this line is the cause, at least assuming that the stdin descriptor was opened correctly. This code appears to buffer the stream until Also, it should probably reset the |
Since this is unrelated to wasmtime, maybe the issue should be discussed on the |
Thanks for opening the issue there, @flavio. I'll close this issue for now in favor of jedisct1/as-wasi#95. |
I hope I'm opening this bug on the right GitHub repo, if not please forgive me 馃槄
I've written a simple "echo" program using AssemblyScript and as-wasi. The program reads the user input from STDIN and writes it back to STDOUT.
Unfortunately it looks like I can never get back the input I enter.
This the source code of the AssemblyScript program I'm running:
The program can be compiled to a WASM binary by doing:
And it can be run in this way:
The program will start and I'll be able to enter my text. The program will keep reading from STDIN until I send the
EOF
symbol (I'm on Linux ->CTRL-D
).Unfortunately the
input
variable is alwaysnull
.if so, with which assertion?
I would expect the WASM program to be able to read data from stdin. The
input
object should hold the text I entered on my terminal.This is my stack:
as-wasi
: 0.4.0(Rust version, operating system, architecture...)
I'm running on a x86_64 Linux box that has openSUSE Tumbleweed
More information...
The
as-wasi
handles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor0
for STDIN,1
for STDOUT and2
for STDERR. In my tests it looks like opening the file descriptor0
always returns anull
instance ofDescriptor
; this doesn't happen with STDOUT and STDERR.The same issue happens also when running the program through a custom made Go program I wrote leveraging
wasmtime-go
.In that case I even tried to start the WASM binary not by inheriting the parent STDIN, but instead by using a text file I previously created. Also in this case the WASM binary got a
null
object when reading from the STDIN.Relevant: a similar WASM binary, generated by translating Rust -> WASM, just works as expected.
Thanks for any kind of help you can give me. I gotta say, WebAssembly and wasmtime are really cool :)
The text was updated successfully, but these errors were encountered: