flavio edited Issue #2373:
I hope I'm opening this bug on the right GitHub repo, if not please forgive me :sweat_smile:
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.
- What are the steps to reproduce the issue?
This the source code of the AssemblyScript program I'm running:
import "wasi" import {Console} from "as-wasi" Console.log("type something"); let input: string | null; let msg : string = "nothing"; input = Console.readAll(); if (input != null) { msg = input! } Console.log('I got: ' + msg);
The program can be compiled to a WASM binary by doing:
$ asc echo.ts -b echo.wasm
And it can be run in this way:
$ wasmtime run echo.wasm
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
.
- What do you expect to happen? What does actually happen? Does it panic, and
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.
- Which Wasmtime version / commit hash / branch are you using?
This is my stack:
* wasmtime: 0.21.0
* AssemblyScript: 0.17.1
*as-wasi
: 0.4.0
- If relevant, can you include some extra information about your environment?
(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 anull
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 :)
alexcrichton commented on Issue #2373:
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)
peterhuene commented on Issue #2373:
Could it be this line that returns null when bytes read = 0?
torch2424 commented on Issue #2373:
Thanks for looping me in @alexcrichton :smile:
And yes, @peterhuene , I bet it's falling through to the bottom to return 0 :smile:
@flavio I was able to reproduce this, and what caught my interest was:
The as-wasi handles STDIN/STDOUT/STDERR by using instances of the Descriptor class. The library simply opens the file descriptor 0 for STDIN, 1 for STDOUT and 2 for STDERR. In my tests it looks like opening the file descriptor 0 always returns a null instance of Descriptor; this doesn't happen with STDOUT and STDERR.
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 :smile:
flavio commented on Issue #2373:
@torch2424 it's fine on Unix to have the STDIN -> 0, STDOUT -> 1 and STDERR -> 2. I'm not surprised by that :)
peterhuene edited a comment on Issue #2373:
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)?
sunfishcode commented on Issue #2373:
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.
jedisct1 commented on Issue #2373:
Hi,
This is a misunderstanding of what the
readAll()
function does inas-wasi
, and the behavior would be the same with any runtime.The
readAll()
function reads a stream until the end. And a newline doesn't indicate the end of a stream.
stdin
is an endless stream, unless it is manually closed from a console (Control-D), or the content of a file has been redirected to it (command < file.txt
) and the whole file has been read.In order to read a line of text, you need to read bytes until you reach a
\n
or\r\n
sequence.The current version of
as-wasi
includes areadLine()
function (both inDescriptor
andConsole
) that reads a line of text, and converts it into an AssemblyScript string. This is probably the function you should use here.
peterhuene commented on Issue #2373:
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
null
returned even with a CTRL-D.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
fd_read
returns 0, at which point it returnsnull
instead of the buffered input.
peterhuene edited a comment on Issue #2373:
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
null
returned even with a CTRL-D.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
fd_read
returns 0, at which point it returnsnull
instead of the buffered input.Also, it should probably reset the
read
variable each iteration (or simply returnnull
for an error returned byfd_read
rather than thebreak
) otherwise a successful read followed by an error will result in partial data being returned rather thannull
.
peterhuene edited a comment on Issue #2373:
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
null
returned even with a CTRL-D.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
fd_read
returns 0 bytes read, at which point it returnsnull
instead of the buffered input.Also, it should probably reset the
read
variable each iteration (or simply returnnull
for an error returned byfd_read
rather than thebreak
) otherwise a successful read followed by an error will result in partial data being returned rather thannull
.
peterhuene edited a comment on Issue #2373:
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
null
returned fromreadAll
even with a CTRL-D.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
fd_read
returns 0 bytes read, at which point it returnsnull
instead of the buffered input.Also, it should probably reset the
read
variable each iteration (or simply returnnull
for an error returned byfd_read
rather than thebreak
) otherwise a successful read followed by an error will result in partial data being returned rather thannull
.
jedisct1 commented on Issue #2373:
Since this is unrelated to wasmtime, maybe the issue should be discussed on the
as-wasi
repository instead?
flavio commented on Issue #2373:
I think the problem is that @flavio was observing
null
returned fromreadAll
even with a CTRL-D.Yes, exactly.
@jedisct1, sure if you want I can close this issue and open a new one one the
as-wasi
repository
peterhuene commented on Issue #2373:
Thanks for opening the issue there, @flavio. I'll close this issue for now in favor of jedisct1/as-wasi#95.
peterhuene closed Issue #2373:
I hope I'm opening this bug on the right GitHub repo, if not please forgive me :sweat_smile:
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.
- What are the steps to reproduce the issue?
This the source code of the AssemblyScript program I'm running:
import "wasi" import {Console} from "as-wasi" Console.log("type something"); let input: string | null; let msg : string = "nothing"; input = Console.readAll(); if (input != null) { msg = input! } Console.log('I got: ' + msg);
The program can be compiled to a WASM binary by doing:
$ asc echo.ts -b echo.wasm
And it can be run in this way:
$ wasmtime run echo.wasm
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
.
- What do you expect to happen? What does actually happen? Does it panic, and
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.
- Which Wasmtime version / commit hash / branch are you using?
This is my stack:
* wasmtime: 0.21.0
* AssemblyScript: 0.17.1
*as-wasi
: 0.4.0
- If relevant, can you include some extra information about your environment?
(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 anull
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 :)
Last updated: Dec 23 2024 at 13:07 UTC